https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80617
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 11 May 2018, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80617 > > --- Comment #12 from Marc Glisse <glisse at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #11) > > Dup of PR23094 (and fixed). > > Richard, comment #9 shows that the original testcase is only half-fixed > (though > the other half seems hard to fix). Does this mean you consider the second half > as WONTFIX? So ... __old_val_5 = MEM[(void * &)a_2(D)]; MEM[(void * &)a_2(D)] = 0B; __old_val_6 = MEM[(void * &)b_3(D)]; MEM[(void * &)b_3(D)] = 0B; MEM[(void * &)a_2(D)] = __old_val_6; _7 = MEM[(void * &)b_3(D)]; MEM[(void * &)b_3(D)] = __old_val_5; if (_7 != 0B) .. the logic is that if a and b alias they have to exactly overlap and thus _7 is __old_val_6 which is then 0. While it might be quite interesting to try considering this it requires a bit too much magic for the current machinery ;) We've already value-numbered __old_val_6 but we would need to re-visit its def with the constraint a_2 == b_3 so this would add some back-propagation to the forward-working value-numbering. The PR23094 fix is already somewhat limited and I'm not holding my breath on the above given it doesn't fit any existing optimization algorithm very well... (complexity also explodes once you need to consider any combination of exact-overlap aliases). We can re-open this to track the issue.
