http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> 2012-05-24 07:29:52 UTC --- On Thu, 24 May 2012, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |jakub at gcc dot gnu.org > > --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-24 > 07:21:28 UTC --- > We have > x_9 = *D.1724_8; > ... > x_16 = ASSERT_EXPR <x_9, x_9 != 0>; > D.1726_10 = found_x_2 != 0; > D.1727_11 = x_16 <= prev_x_3; > ... > # found_x_2 = PHI <0(2), 1(6)> > # prev_x_3 = PHI <prev_x_4(D)(2), x_16(6)> > ... > loop to top > > prev_x_3: ~[0, 0] EQUIVALENCES: { x_9 } (1 elements) > prev_x_4(D): UNDEFINED > x_9: VARYING > x_16: ~[0, 0] EQUIVALENCES: { x_9 } (1 elements) > > I think the problem are the equivalences, or their handling. When we merge on > PHI UNDEFINED with ~[0, 0] EQUIVALENCES: { x_9 } into the latter, we push the > equivalence into the next loop iteration where x_9 already can have a > different > value. I guess either we could drop all equivalences when merging UNDEFINED > with some range with EQUIVALENCES, or at least those equivalences which don't > dominate the PHI. Richard, what do you think? Yes, I think we need to clear all equivalences in vrp_meet
