https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #42 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
#pragma GCC diagnostic is handled in the FEs when it sees the pragmas among
tokens it gets from the preprocessor.
So, for diagnostics emitted from the preprocessor, it depends on how to FE uses
the preprocessor. The C++ FE preprocesses everything into a long array of
tokens and then parses that, so no GCC diagnostic pragmas can affect any
diagnostics from the preprocessor.
The C FE uses the preprocessor whenever it needs another token, has a 2 token
look-ahead if needed but in certain cases can grab far more tokens from the
preprocessor and store them for later use (see c_parser_peek_nth_token_raw
etc.).
So, unless it does that (which is currently used mostly for [[]] attributes or
some OpenMP constructs) and when the usual 2 token look-ahead likely doesn't
cross the diagnostic pragma that needs to be parsed, GCC diagnostic likely
works for C most of the time.
I think if we want to make GCC diagnostic pragma work for C++ preprocessor
diagnostics, we'd need to either parse them also in the preprocessor and for
the options preprocessor cares about remember what it does, or when filling up
the large array of tokens in the C++ FE parse (silently?) the pragmas too,
invoke the diagnostic APIs to ignore or promote to -Werror etc. as it goes,
and at the end when CPP_EOF is encountered reset the state to the start at the
start of the compilation.
Doing separate parsing in the preprocessor would have an advantage that it
would
also affect -E, which currently isn't affected for either C or C++ I think,
but due to the way C FE works would need need separate warning state for
preprocessor diagnostics and for the FE diagnostics.
Doing it in the C++ FE would be easier, but -E would ignore them.
