[Bug tree-optimization/108467] New: false positive -Wmaybe-uninitialized warning at -O1 or higher

[Bug tree-optimization/108467] New: false positive -Wmaybe-uninitialized warning at -O1 or higher

[vincent-gcc at vinc17 dot net]

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

            Bug ID: 108467
           Summary: false positive -Wmaybe-uninitialized warning at -O1 or
                    higher
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider the following code, derived from MPFR's sub1sp.c (where the issue
occurred since at least GCC 4.9.4 and the warning was silenced with the "sh =
sh" trick via an INITIALIZED() macro):

extern long emin;
extern long emax;

int f(void);

int g(void)
{
  int sh, rb, sb;

  if (f())
    rb = sb = 0;
  else
    {
      sh = f();
      sb = f();
      rb = f();
    }

  (0 >= emin && 0 <= emax) || (f(), __builtin_unreachable(), 0);
  if (rb == 0 && sb == 0)
    return 0;
  else
    return sh;
}

With gcc-12 (Debian 12.2.0-14) 12.2.0, I get:

$ gcc-12 -O2 -Wmaybe-uninitialized -c tst.c
tst.c: In function ‘g’:
tst.c:23:12: warning: ‘sh’ may be used uninitialized [-Wmaybe-uninitialized]
   23 |     return sh;
      |            ^~
tst.c:8:7: note: ‘sh’ was declared here
    8 |   int sh, rb, sb;
      |       ^~

The warning also occurs at -O1 and -O3. It disappears if I slightly modify the
code.

Note: During the code reduction, I also got the warning, but with a different
location. However, the code was more complex, and I've already reported
PR108466 about a location issue (where the -Wmaybe-uninitialized is correct).
So I haven't reported an additional issue about the location.

[Bug tree-optimization/108467] false positive -Wmaybe-uninitialized warning at -O1 or higher

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
      Known to fail|                            |4.1.2
   Last reconfirmed|                            |2023-01-19
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---

After normalization [USE]:
        _7 = PHI <0(13), sh_4(8)>
  is conditional on:
        ((NOT (_3 == 0)) AND (emax.3_2 >= 0) AND (emin.2_1 <= 0))


  _3 = rb_5 | sb_6;
  if (_3 == 0)


Confirmed.

[Bug tree-optimization/108467] false positive -Wmaybe-uninitialized warning at -O1 or higher

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's some special code dealing with checking on a conditional set value
but that's confused by the two-value guard here.

[Bug tree-optimization/108467] false positive -Wmaybe-uninitialized warning at -O1 or higher

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjames at gcc dot gnu.org

--- Comment #3 from Sam James <sjames at gcc dot gnu.org> ---
For 14/15, it seems gone with -O2, but I see it with -Og.

[Bug tree-optimization/108467] false positive -Wmaybe-uninitialized warning at -O1 or higher

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Sam James from comment #3)
> For 14/15, it seems gone with -O2, but I see it with -Og.

The warning still occurs with -O1 too.