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?
