[Bug middle-end/103036] New: incorrect #pragma GCC diagnostic suppression for macro expansion and -Wuninitialized

[Bug middle-end/103036] New: incorrect #pragma GCC diagnostic suppression for macro expansion and -Wuninitialized

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103036

            Bug ID: 103036
           Summary: incorrect #pragma GCC diagnostic suppression for macro
                    expansion and -Wuninitialized
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The test case below shows that suppressing -Wuninitialized by #pragma GCC
diagnostic doesn't work the same as it does for other warnings (-Wrray-bounds
in this instance, but most other warnings behave like it).  This makes it
difficult for users to control -Wuninitialized (and -Wmaybe-uninitialized),
compounding their frustration when they run into one of its false positives.

The reason for the difference is that tree-ssa-uninit.c calls
linemap_resolve_location (line_table, location, LRK_SPELLING_LOCATION, NULL)
before using location, which other warnings don't do.  The call was introduced
in r186971 along with a test for its effect, gcc.dg/cpp/pragma-diagnostic-2.c,
with the goal to improve the macro expansion output printed by GCC with
-ftrack-macro-expansion as well as its interaction with on #pragma GCC
diagnostic.  It seems to me that the change was ill thought out: I can think of
no reason why -Wunitialized should be treated differently from all other
warnings.

$ cat a.c && gcc -O2 -S -Wall -Werror a.c
#define X(i) f (a[i]);

int f (int);

int g (void)
{
  int a[3];
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wuninitialized"
  return X (1);
#pragma GCC diagnostic pop
}

int h (void)
{
  int a[] = { 1, 2, 3 };
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Warray-bounds"
  return X (3);
#pragma GCC diagnostic pop
}
a.c: In function ‘g’:
a.c:1:14: error: ‘a’ is used uninitialized [-Werror=uninitialized]
    1 | #define X(i) f (a[i]);
      |              ^~~~~~~~
a.c:10:10: note: in expansion of macro ‘X’
   10 |   return X (1);
      |          ^
a.c:7:7: note: ‘a’ declared here
    7 |   int a[3];
      |       ^
a.c: In function ‘h’:
a.c:1:14: warning: array subscript 3 is above array bounds of ‘int[3]’
[-Warray-bounds]
    1 | #define X(i) f (a[i]);
      |              ^~~~~~~~
a.c:19:10: note: in expansion of macro ‘X’
   19 |   return X (3);
      |          ^
a.c:16:7: note: while referencing ‘a’
   16 |   int a[] = { 1, 2, 3 };
      |       ^
cc1: all warnings being treated as errors

[Bug middle-end/103036] incorrect #pragma GCC diagnostic suppression for macro expansion and -Wuninitialized

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103036

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Blocks|                            |24639
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=90400

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
See also pr90400 which is about using a _Pragma to suppress
-Wmaybe-uninitialized in macros.  Removing the linemap_resolve_location() calls
from tree-ssa-uninit.c isn't enough to fix that bug but it's prerequisite for a
consistent behavior for the suppression of all warnings.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/103036] incorrect #pragma GCC diagnostic suppression for macro expansion and -Wuninitialized

[lhyatt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103036

Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
                 CC|                            |lhyatt at gcc dot gnu.org

--- Comment #2 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
This was fixed by r13-2994. Sorry for not tagging this PR, I came upon the
issue via PR69543 comment 9 instead.

Regarding PR90400, I think that is about the way the token streamer class works
for gcc -E, and it needs to handle _Pragma distinctly from #pragma. I will look
at it too sometime.