https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116213
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Keywords| |missed-optimization
Target Milestone|--- |14.3
Last reconfirmed| |2024-08-05
Ever confirmed|0 |1
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
This looks like a missed optimization:
<bb 2> [local count: 153437707]:
D.3193 ={v} {CLOBBER(bob)};
MEM[(struct irange *)&D.3193] ={v} {CLOBBER(bob)};
MEM[(struct __as_base &)&D.3193] ={v} {CLOBBER(bob)};
MEM[(struct wide_int_storage *)&D.3193].precision = 0;
MEM[(struct __as_base &)&D.3193 + 16] ={v} {CLOBBER(bob)};
MEM[(struct wide_int_storage *)&D.3193 + 16B].precision = 0;
MEM[(struct __as_base &)&D.3193 + 32] ={v} {CLOBBER(bob)};
MEM[(struct wide_int_storage *)&D.3193 + 32B].precision = 0;
MEM[(struct __as_base &)&D.3193 + 48] ={v} {CLOBBER(bob)};
MEM[(struct wide_int_storage *)&D.3193 + 48B].precision = 0;
MEM[(struct __as_base &)&D.3193 + 64] ={v} {CLOBBER(bob)};
MEM[(struct wide_int_storage *)&D.3193 + 64B].precision = 0;
MEM[(struct __as_base &)&D.3193 + 80] ={v} {CLOBBER(bob)};
MEM[(struct wide_int_storage *)&D.3193 + 80B].precision = 0;
MEM[(struct __as_base &)&D.3193 + 96] ={v} {CLOBBER(bob)};
MEM[(struct wide_int_storage *)&D.3193 + 96B].precision = 0;
hwi_with_prec_p.0_17 = hwi_with_prec_p;
if (hwi_with_prec_p.0_17 <= 3)
goto <bb 3>; [33.00%]
else
goto <bb 4>; [67.00%]
<bb 4> [local count: 102803262]:
xi ={v} {CLOBBER(bob)};
MEM <unsigned long> [(void *)&xi] = 0;
xi.D.2880.precision = hwi_with_prec_p.0_17;
_21 = MEM[(struct wide_int_storage *)&D.3193].precision; // <-- zero?
if (hwi_with_prec_p.0_17 != _21)
goto <bb 22>; [10.00%]
else
goto <bb 5>; [90.00%]
<bb 5> [local count: 92522935]:
if (_21 != 4)
goto <bb 6>; [14.93%]
else
goto <bb 23>; [85.07%]
<bb 6> [local count: 13809394]:
_107 = MEM[(struct wide_int_storage *)&D.3193].valp; // <-- this is diagnosed
storage_ref::get_val (&xi.D.2880);
goto <bb 19>; [100.00%]
we don't know anything about hwi_with_prec_p, so not sure if we can prune
the offended path. But:
<bb 19> [local count: 39638074]:
# _51 = PHI <_107(6), 0B(7)>
*_51 = 0;
goto <bb 18>; [100.00%]
so at least *0 = 0 could be isolated, pruning the 5->23 path (but there's
a storage_ref::get_val call that could terminate the process).
Note I only looked at the reduced testcase. As usual late diagnostics
depend on optimization to prune unreachable paths. The revision in
question simply retained the fact that some memory is not initialized
in the IL until later uninit analysis.
