https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the testcase in comment#16 we have ifcombine doing
<bb 4> [local count: 477815112]:
- if (v_12 == 1)
- goto <bb 6>; [34.00%]
- else
- goto <bb 5>; [66.00%]
-
- <bb 5> [local count: 315357972]:
- if (LookupFlags_5 != 0)
- goto <bb 6>; [50.00%]
+ _19 = v_12 == 1;
+ _20 = LookupFlags_5 | _19;
+ if (_20 != 0)
+ goto <bb 5>; [67.00%]
that at least accesses 'LookupFlags_5' without checking v_12 is either zero
or one. This exposes an uninitialized read of LookupFlags_5 on the path
from entry, even actually at runtime. PHI-OPT then makes tt value
dependent on this uninitialized variable and I suspect things go downhill
from there.
Note it's not obvious at all that 'LookupFlags_5' may be uninitialized here,
so ifcombine might need to use mark_ssa_maybe_undefs to try to conservatively
catch those.
