https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100033
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Version|unknown |11.0
Last reconfirmed| |2021-04-12
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is an "inconsistency" of handling the test on the uninitialized variable
'e'. "Conveniently" at -O2 we see
<bb 5> [local count: 4880644681]:
# e_16 = PHI <e_17(D)(4), i.0_3(12)>
if (b.5_7 != 0)
goto <bb 12>; [89.00%]
else
goto <bb 6>; [11.00%]
<bb 12> [local count: 4343773769]:
goto <bb 5>; [100.00%]
<bb 6> [local count: 536870912]:
if (e_16 == 0)
goto <bb 7>; [33.00%]
and thus we merge e_17(D) and i.0_3(12) as i.0_3(12) which is know to be
non-zero at this point which makes VRP optimize the call out. At -O3 we
instead see
<bb 5> [local count: 536870912]:
if (e_17(D) == 0)
goto <bb 7>; [33.00%]
else
goto <bb 8>; [67.00%]
<bb 13> [local count: 4343773769]:
<bb 6> [local count: 4343773769]:
goto <bb 13>; [100.00%]
<bb 7> [local count: 177167401]:
foo ();
<bb 8> [local count: 1073741824]:
return 0;
which we handle by not doing anything (we could decide to take the test
as always true or always false but the choice would be arbitrary).
Not sure if it is worth tackling this as a "bug" at all. Possibly it's
a duplicate of the issues that ask for path isolation to replace the
e_17(D) == 0 test with a runtime trap (and optionally __builtin_unreachable ()
for maximum [size] optimization).
