https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65686
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |diagnostic, | |missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2015-04-15 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.2 Ever confirmed|0 |1 --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- It's (good) <bb 2>: _4 = e_3(D)->pu; if (&x != _4) goto <bb 3>; else goto <bb 5>; <bb 5>: goto <bb 4>; <bb 3>: _5 = MEM[(char * {ref-all})_4]; MEM[(char * {ref-all})&x] = _5; <bb 4>: _7 = x; x ={v} {CLOBBER}; return _7; vs. (bad) <bb 2>: _4 = e_3(D)->pu; if (&x != _4) goto <bb 4>; else goto <bb 3>; <bb 3>: pretmp_9 = x; goto <bb 5>; <bb 4>: _5 = MEM[(char * {ref-all})_4]; <bb 5>: # prephitmp_10 = PHI <pretmp_9(3), _5(4)> x ={v} {CLOBBER}; return prephitmp_10; that's a missed PRE opportunity in the good case (not sure why we use unsigned int for the memcpy inlining - ah, because it goes the new single load/store case in gimple_fold_builtin_memory_op). PRE should still be able to handle. Only after PRE we hit the very special case where uninit warns about memory reads (no store before the reads). For this case inconsistencies are very much expected... But the testcase also shows a missed optimization opportunity because &x can never be equal to e->pu (PR13962).