From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3F4A13858415; Wed, 6 Oct 2021 14:40:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F4A13858415 From: "jakub at gcc dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.7.0 X-Bugzilla-Keywords: diagnostic, documentation X-Bugzilla-Severity: minor X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 14:40:05 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D53431 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #42 from Jakub Jelinek --- #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 tok= en 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.=