diff options
author | Peter Klausler <pklausler@nvidia.com> | 2025-01-14 13:01:31 -0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-01-14 13:01:31 -0800 |
commit | 4a3e4b99b9ab3016afe8b02c4f83f24635964f4e (patch) | |
tree | 646b50ebc4d4978572e82ee7e445acc6c8b6c5a6 /llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | |
parent | 9f0f54a6290ead2e1581d75582759822a19fd885 (diff) | |
download | llvm-4a3e4b99b9ab3016afe8b02c4f83f24635964f4e.zip llvm-4a3e4b99b9ab3016afe8b02c4f83f24635964f4e.tar.gz llvm-4a3e4b99b9ab3016afe8b02c4f83f24635964f4e.tar.bz2 |
[flang] Adjust prescanner fix for preprocessing (#122779)
Commas being optional in FORMAT statements, the tokenization of things
like 3I9HHOLLERITH is tricky. After tokenizing the initial '3', we don't
want to then take apparent identifier "I9HHOLLERITH" as the next token.
So the prescanner just consumes the letter ("I") as its own token in
this context.
A recent bug report complained that this can lead to incorrect results
when (in this case) the letter is a defined preprocessing macro. I
updated the prescanner to check that the letter is actually followed by
an instance of a problematic Hollerith literal.
And this broke two tests in the Fujitsu Fortran test suite that Linaro
runs, as it couldn't detect a following Hollerith literal that wasn't on
the same source line. We can't do look-ahead line continuation
processing in NextToken(), either.
So here's a second attempt at fixing the original problem: namely, the
letter that follows a decimal integer token is checked to see whether
it's the name of a defined macro.
Diffstat (limited to 'llvm/lib/Bitcode/Writer/BitcodeWriter.cpp')
0 files changed, 0 insertions, 0 deletions