[Bug middle-end/78993] [9/10/11 Regression] False positive from -Wmaybe-uninitialized

["msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.1.0, 5.3.0, 6.2.0, 7.0    |10.2.0, 11.0, 5.5.0, 6.4.0,
                   |                            |7.2.0, 8.3.0, 9.1.0
   Last reconfirmed|2017-01-05 00:00:00         |2021-4-1
            Summary|False positive from         |[9/10/11 Regression] False
                   |-Wmaybe-uninitialized       |positive from
                   |                            |-Wmaybe-uninitialized

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
Reconfirmed with GCC 11 as a regression introduced in r219703 (GCC 5.0).  The
warning for the smaller test case started with r147852 (GCC 4.5.0).

(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to Andrew Pinski from comment #4)
> >   # i_5 = PHI <i_3(D)(3), i_4(4)>
> >   # j_27 = PHI <j_6(3), j_26(4)>
> >   # prephitmp_7 = PHI <0(3), prephitmp_17(4)>
> >   _14 = i_5 > 9;
> >   _18 = prephitmp_7 | _14;
> >   if (_18 != 0)
> >     goto <bb 6>; [44.99%]
> >   else
> >     goto <bb 7>; [55.01%]
> > 
> > 
> > Most likely conditional warning does not understand the above case :).
> 
> If the reason is the prephitmp_7 | _14, then this is PR42145

It doesn't understand it because it only deals with predicates of the form
<NAME> <OPERATOR> <CONSTANT> so when it sees (_18 != 0)" and tries to compare
it to another predicate it can only do it if the other one also involves _18
and that's not the case (there's only one _18 in the IL and that's this one).

But I don't think it should matter in this case because it seems clear in the
IL (as clear as anything can be) that j is undefined when (i < 0 && i > j)
holds and used when (i >= 0 && i < j) holds, and those two are mutually
exclusive.  Yet when the warning logic tries to see if the predicate guarding
the definition of the variable is a superset of the one guarding its use is
winds up looking at:

def     i_3(D) >= 0 && i_3(D) < j_6 (expanded)
        AND (NOT (i_3(D) < 0), NOT (i_3(D) >= j_6))
use     (prephitmp_7 | i_5 > 9) == 0 (expanded)
        NOT (_17 != 0)

Here's GCC 11 IL for the small test case:

int foobar (int i)
{
  int j;
  int i;
  int j;
  int _1;
  _Bool prephitmp_7;
  _Bool _16;
  _Bool _17;
  _Bool prephitmp_20;

  <bb 2> [local count: 1073741824]:
  # .MEM_9 = VDEF <.MEM_2(D)>
  j_6 = rand ();
  if (i_3(D) >= j_6)
    goto <bb 8>; [55.78%]
  else
    goto <bb 3>; [44.22%]

  <bb 3> [local count: 474808632]:
  if (i_3(D) < 0)
    goto <bb 9>; [13.00%]
  else
    goto <bb 10>; [87.00%]

  <bb 10> [local count: 413074919]:
  goto <bb 5>; [100.00%]

  <bb 9> [local count: 61733713]:

  <bb 4> [local count: 273804168]:
  # j_26 = PHI <j_6(9), j_12(D)(13)>
  # prephitmp_20 = PHI <0(9), 1(13)>
  # .MEM_10 = VDEF <.MEM_9>
  i_4 = rand ();

  <bb 5> [local count: 686879088]:
  # i_5 = PHI <i_3(D)(10), i_4(4)>
  # .MEM_8 = PHI <.MEM_9(10), .MEM_10(4)>
  # j_27 = PHI <j_6(10), j_26(4)>
  # prephitmp_7 = PHI <0(10), prephitmp_20(4)>
  _16 = i_5 > 9;
  _17 = prephitmp_7 | _16;
  if (_17 != 0)
    goto <bb 11>; [0.00%]
  else
    goto <bb 12>; [100.00%]

  <bb 12> [local count: 686879088]:
  goto <bb 7>; [100.00%]

  <bb 11> [local count: 0]:

  <bb 6> [local count: 386862736]:
  # .MEM_11 = PHI <.MEM_8(11), .MEM_9(14)>

  <bb 7> [local count: 1073741824]:
  # _1 = PHI <0(6), j_27(12)>
  # .MEM_25 = PHI <.MEM_11(6), .MEM_8(12)>
  # VUSE <.MEM_25>
  return _1;

  <bb 8> [local count: 598933192]:
  if (i_3(D) < 0)
    goto <bb 13>; [35.41%]
  else
    goto <bb 14>; [64.59%]

  <bb 14> [local count: 386862736]:
  goto <bb 6>; [100.00%]

  <bb 13> [local count: 212070456]:
  goto <bb 4>; [100.00%]

}