[Bug c/102381] New: unexpected -Wmaybe-uninitialized

[Bug c/102381] New: unexpected -Wmaybe-uninitialized

[hv at crypt dot org]

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

            Bug ID: 102381
           Summary: unexpected -Wmaybe-uninitialized
           Product: gcc
           Version: 7.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hv at crypt dot org
  Target Milestone: ---

This is reduced from perl source code. Reduction was a challenge, so there's a
risk the essence may have been lost.

The following code gives a -Wmaybe-uninitialized warning with each of "gcc-7
(Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0", "gcc-9 (Ubuntu 9.2.1-17ubuntu1~18.04.1)
9.2.1 20191102" and self-built "gcc (GCC) 11.2.0".

% cat test.c
extern void fail(void) __attribute__((__noreturn__));
int** f(void);

extern int *ip;
extern int i2, i3; 

void test(int i1) {
    int **ipp;

    if (i1) {
        ipp = f();
    }
    for (int i4 = 0; i4 < i2; i4++) {
        if (((i3 & 1) != 1) && ((i3 & 3) != 3))
            fail();
    }
    if (i1) {
        ip = *ipp;
    }
    return;
}
% gcc -c -Wmaybe-uninitialized -O1 test.c
test.c: In function 'test':
test.c:18:14: warning: 'ipp' may be used uninitialized in this function
[-Wmaybe-uninitialized]
         ip = *ipp;
              ^~~~
% 

I think it should be clear that i1 does not change within this code, and the
'ip = *ipp' therefore cannot be reached without also previously having reached
'ipp = f()'. The sensitivity of the intervening code suggests this must be a
bug, eg replacing 'if (((i3 & 1) != 1) && ((i3 & 3) != 3))' with 'if ((i3 & 3)
!= 3)' makes the warning disappear.

[Bug tree-optimization/102381] unexpected -Wmaybe-uninitialized

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-09-17

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

....

[AFTER NORMALIZATION -- [DEF]:
ipp_28 = PHI <ipp_23(17), ipp_11(D)(15)>
is guarded by :

i2.2_26 > 0 (.AND.) i1_10(D) != 0

....

[AFTER NORMALIZATION -- [USE]:
ipp_27 = PHI <ipp_28(21), ipp_23(18)>
is guarded by :

i1_10(D) != 0 (.AND.)  (.NOT.) i4_17 < prephitmp_25 (.AND.) _2 == 0
(.OR.)
i1_10(D) != 0 (.AND.)  (.NOT.) i4_17 < prephitmp_25 (.AND.) i3.0_1 & 1

...
  _2 = i3.0_1 & 1;

So there is a missing simplification
It should have been:

i1_10(D) != 0 (.AND.)  (.NOT.) i4_17 < prephitmp_25

prephitmp_25 is defined as:
  # prephitmp_25 = PHI <i2.2_26(17), i2.2_21(15)>
So i2.2_26 (as i2.2_21 is the one on the branch which would have been
uninitialized).
So we are down to:
i1_10(D) != 0 (.AND.)  (.NOT.) i4_17 < i2.2_26

i4_17 is the loop IV so it should be discarded.

[Bug tree-optimization/102381] unexpected -Wmaybe-uninitialized with noreturn inside loop and conditional setting of variable

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The noreturn messes up the anlysis fully.