https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498
Lewis Hyatt <lhyatt at gcc dot gnu.org> 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 <lhyatt at gcc dot gnu.org> ---
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 processed.
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 function,
rather the location of the relevant tokens, but I am not sure all the details
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:
======
static void f() {} _Pragma("GCC diagnostic error \"-Wunused-function\"")
======
Compiled without any other arguments, it works with gcc -x c++ and with gcc
-save-temps, but it fails with gcc -x c.
