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.

  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: link
Be 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).