From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1CE16385C30B; Thu, 7 Jul 2022 14:00:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1CE16385C30B From: "lhyatt at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent Date: Thu, 07 Jul 2022 14:00:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: 9.3.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: lhyatt 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 everconfirmed cf_reconfirmed_on bug_status 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: Thu, 07 Jul 2022 14:00:08 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97498 Lewis Hyatt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lhyatt at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed| |2022-07-07 Status|UNCONFIRMED |NEW --- Comment #1 from Lewis Hyatt --- This is closely related to PR69543, but it's not quite the same. That PR is about the use of input_location when processing a "#pragma GCC diagnostic ignored"; this one is about the use of input_location when processing a pop rather. In c-pragma.cc line ~943 we call diagnostic_pop_diagnostics (global_dc, input_location); When processing the line: static int f(int p) {return p + 1;} _Pragma("GCC diagnostic pop"); In C++ mode, input_location points to the _Pragma and so it works fine. In preprocess mode (gcc -E or gcc with -save-temps), it's fine also because the _Pragma turns into a #pragma on the next line before being actually proces= sed. In C mode though, input_location points to the start of the line and hence = the pop takes effect too early which leads to the issue. It feels to me like we shouldn't use input_location anywhere in this functi= on, rather the location of the relevant tokens, but I am not sure all the detai= ls of that, will see if anyone on PR69543 has ideas as well. Here is a one-line test case that reveals the same problem with using input_location while processing the GCC diagnostic pragma, i.e. exactly PR69543's case: =3D=3D=3D=3D=3D=3D static void f() {} _Pragma("GCC diagnostic error \"-Wunused-function\"") =3D=3D=3D=3D=3D=3D Compiled without any other arguments, it works with gcc -x c++ and with gcc -save-temps, but it fails with gcc -x c.=