public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic Date: Wed, 06 Oct 2021 14:40:04 +0000 [thread overview] Message-ID: <bug-53431-4-oJeGE3HyOE@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-53431-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2021-10-06 14:40 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-05-21 8:03 [Bug c++/53431] New: C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef" ml.lattuada at libero dot it 2013-02-17 17:04 ` [Bug c++/53431] " rainarchitect at gmail dot com 2013-03-03 4:10 ` markus at oberhumer dot com 2013-07-12 9:20 ` nomegenerico at email dot it 2013-11-16 18:13 ` rainarchitect at gmail dot com 2013-11-16 19:51 ` manu at gcc dot gnu.org 2013-11-16 20:23 ` manu at gcc dot gnu.org 2014-09-05 17:42 ` [Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic manu at gcc dot gnu.org 2015-06-03 8:27 ` manu at gcc dot gnu.org 2015-07-20 9:38 ` manu at gcc dot gnu.org 2015-07-22 0:00 ` noloader at gmail dot com 2015-07-22 10:51 ` redi at gcc dot gnu.org 2015-07-22 11:24 ` noloader at gmail dot com 2015-07-23 10:34 ` noloader at gmail dot com 2015-07-23 10:47 ` redi at gcc dot gnu.org 2015-07-23 11:32 ` manu at gcc dot gnu.org 2015-07-23 13:20 ` manu at gcc dot gnu.org 2015-07-23 23:26 ` noloader at gmail dot com 2015-07-30 17:22 ` miyuki at gcc dot gnu.org 2021-02-27 11:24 ` noloader at gmail dot com 2021-06-03 12:04 ` redi at gcc dot gnu.org 2021-10-06 14:40 ` jakub at gcc dot gnu.org [this message] 2021-12-01 17:43 ` egallager at gcc dot gnu.org 2021-12-04 17:48 ` lhyatt at gcc dot gnu.org 2021-12-19 11:55 ` pinskia at gcc dot gnu.org 2021-12-19 19:50 ` manu at gcc dot gnu.org 2021-12-24 21:29 ` lhyatt at gcc dot gnu.org 2022-03-23 0:58 ` pinskia at gcc dot gnu.org 2022-05-25 13:38 ` lhyatt at gcc dot gnu.org 2022-06-29 16:08 ` lhyatt at gcc dot gnu.org 2022-07-06 19:40 ` cvs-commit at gcc dot gnu.org 2022-07-06 19:42 ` lhyatt at gcc dot gnu.org 2022-07-06 22:59 ` lhyatt at gcc dot gnu.org 2022-11-08 22:28 ` redi at gcc dot gnu.org 2022-11-09 0:05 ` markus at oberhumer dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-53431-4-oJeGE3HyOE@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).