[PATCH] preprocessor: Set input_location to the most recently seen token

[PATCH] preprocessor: Set input_location to the most recently seen token

[Lewis Hyatt]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

Hello-

As discussed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598136.html

Here is another short patch that improves "#pragma GCC diagnostic" handling.
Longer term, it will be desirable to make the handling of this pragma
independent of the global input_location. But in the meantime, some glitches
like this one can be readily addressed by making input_location point to
something better. In this case, input_location during preprocessing (-E or
-save-temps) is made to point to the most recently seen token rather than the
beginning of the file. To the best of my knowledge, nothing else besides
"#pragma GCC diagnostic" handling can observe input_location during
token streaming, so this is expected not to have any other
repercussions. Bootstrap + regtest does look clean on x86-64 Linux.

By the way, the new testcase fails when compiled with C++, but it's not
because of pragma handling, it's rather because the C++ frontend changes the
location on the warning to the wrong place. Once done_lexing has been set to
true, it changes the location of all warnings to input_location, however
that's not correct when the location is the cached location of a macro
definition; the original location is preferable. I will file a separate PR
about that, and have xfailed that testcase for now, since I am not quite there
with grokking the reason it behaves this way, and anyway it's not related to
this 1-line fix for gcc -E.

Please let me know how it looks? Thanks!

-Lewis

[-- Attachment #2: input_location_-E.txt --]
[-- Type: text/plain, Size: 3218 bytes --]

[PATCH] preprocessor: Set input_location to the most recently seen token

When preprocessing with -E and -save-temps, input_location points always to the
first character of the current file. This was previously irrelevant because
nothing was called during the token streaming process that would inspect
input_location. But since r13-1544, "#pragma GCC diagnostic" is supported in
preprocess-only mode, and that pragma relies on input_location to decide if a
given source code location is subject to a diagnostic or not. Most diagnostics
work fine anyway, because they are handled as soon as they are seen and so
everything is still seen in the expected order even though all the diagnostic
pragmas are treated as if they applied at the start of the file. One example
that doesn't work correctly is the new testcase, since here the warning is not
triggered until the end of the file and so it is necessary to track the location
properly.

Fixed by setting input_location to point to each token as it is being
streamed, similar to how C++ mode sets it.

gcc/c-family/ChangeLog:

	* c-ppoutput.cc (token_streamer::stream): Update input_location
	prior to streaming each token.

gcc/testsuite/ChangeLog:

	* c-c++-common/pragma-diag-14.c: New test.
	* c-c++-common/pragma-diag-15.c: New test.

diff --git a/gcc/c-family/c-ppoutput.cc b/gcc/c-family/c-ppoutput.cc
index cd38c969ea0..98081ccfbb0 100644
--- a/gcc/c-family/c-ppoutput.cc
+++ b/gcc/c-family/c-ppoutput.cc
@@ -210,6 +210,10 @@ void
 token_streamer::stream (cpp_reader *pfile, const cpp_token *token,
 			location_t loc)
 {
+  /* Keep input_location up to date, since it is needed for processing early
+     pragmas such as #pragma GCC diagnostic.  */
+  input_location = loc;
+
   if (token->type == CPP_PADDING)
     {
       avoid_paste = true;
diff --git a/gcc/testsuite/c-c++-common/pragma-diag-14.c b/gcc/testsuite/c-c++-common/pragma-diag-14.c
new file mode 100644
index 00000000000..618e7e1ef27
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pragma-diag-14.c
@@ -0,0 +1,9 @@
+/* { dg-do preprocess } */
+/* { dg-additional-options "-Wunused-macros" } */
+
+/* In the past, the pragma has erroneously disabled the warning because the
+   location was not tracked properly with -E or -save-temps; check that it works
+   now.  */
+
+#define X /* { dg-warning "-:-Wunused-macros" } */
+#pragma GCC diagnostic ignored "-Wunused-macros"
diff --git a/gcc/testsuite/c-c++-common/pragma-diag-15.c b/gcc/testsuite/c-c++-common/pragma-diag-15.c
new file mode 100644
index 00000000000..d8076b4f93a
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pragma-diag-15.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Wunused-macros" } */
+
+/* In the past, the pragma has erroneously disabled the warning because the
+   location was not tracked properly with -E or -save-temps; check that it works
+   now.
+
+   This test currently fails for C++ but it's not because of the pragma, it's
+   because the location of the macro definition is incorrectly set.  This is a
+   separate issue, will resolve it in a later patch.  */
+
+#define X /* { dg-warning "-:-Wunused-macros" {} { xfail c++ } } */
+#pragma GCC diagnostic ignored "-Wunused-macros"

Re: [PATCH] preprocessor: Set input_location to the most recently seen token

[Joseph Myers]

On Mon, 11 Jul 2022, Lewis Hyatt via Gcc-patches wrote:

> Hello-
> 
> As discussed here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598136.html
> 
> Here is another short patch that improves "#pragma GCC diagnostic" handling.
> Longer term, it will be desirable to make the handling of this pragma
> independent of the global input_location. But in the meantime, some glitches
> like this one can be readily addressed by making input_location point to
> something better. In this case, input_location during preprocessing (-E or
> -save-temps) is made to point to the most recently seen token rather than the
> beginning of the file. To the best of my knowledge, nothing else besides
> "#pragma GCC diagnostic" handling can observe input_location during
> token streaming, so this is expected not to have any other
> repercussions. Bootstrap + regtest does look clean on x86-64 Linux.
> 
> By the way, the new testcase fails when compiled with C++, but it's not
> because of pragma handling, it's rather because the C++ frontend changes the
> location on the warning to the wrong place. Once done_lexing has been set to
> true, it changes the location of all warnings to input_location, however
> that's not correct when the location is the cached location of a macro
> definition; the original location is preferable. I will file a separate PR
> about that, and have xfailed that testcase for now, since I am not quite there
> with grokking the reason it behaves this way, and anyway it's not related to
> this 1-line fix for gcc -E.
> 
> Please let me know how it looks? Thanks!

OK.

-- 
Joseph S. Myers
joseph@codesourcery.com