http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49419
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-15 14:59:50 UTC --- Anyway, the bug is elsewhere, in particular I'd say the bug is that we use the normal SSA_NAME as init value of the second loop instead of the SSA_NAME initialized from ASSERT_EXPR for that. The interesting stmts are: # iD.1254_47 = PHI <[pr49419.c : 15:67] iD.1254_70(6), [pr49419.c : 15:67] iD.1254_69(8), 0(3), 0(21)> ... iD.1254_86 = ASSERT_EXPR <iD.1254_47, iD.1254_47 != nbmaxD.1250_17(D)>; ... iD.1254_85 = ASSERT_EXPR <iD.1254_86, iD.1254_86 > 0>; ... # iD.1254_50 = PHI <[pr49419.c : 19:60] iD.1254_40(18), iD.1254_85(12)> and the second loop sees i_85 as the initial value. Now, first the i_47 setter is walked, with just one of the edges with value 0 executable, so i_47 has [0, 0] range there. Then i_86 is walked, and as var's range is VR_RANGE, while limit range is VR_ANTI_RANGE, surprisingly symbolic range ~[nbmax_17(D), nbmax_17(D)] wins. I'd think [0, 0] would be much better to return, both because it is not symbolic, is quite narrow and is range instead of anti range. After a while, i_50 stmt is walked several times, including using adjust_range_with_scev, which uses i_47 instead of i_85 as init for some reason. At that point it sees it has [0, 0] range and so computes something from that. After a while, i_47 stmt is visited several times, last time resulting into [0, +INF(OVF)] range (see other comments that it ought to be improved, but uninteresting for this bug). So, the PHI setting i_47 is returning SSA_PROP_INTERESTING, which results in all succ edges of that bb to be marked for revisiting. We revisit i_86 stmt, but that again returns the same (uninteresting) ~[nbmax_17(D), nbmax_17(D)] range, which also means that it is SSA_PROP_NOT_INTERESTING. That bb contains just: [pr49419.c : 18:6] nbD.1255_24 = iD.1254_86 + 1; [pr49419.c : 19:3] if (iD.1254_86 > 0) after it, but as i_86's VR didn't change, no other VRs in that bb change either, which means none of the succ bb's of this bb are queued for revisiting. So, I think we should arrange for the actual current ASSERT_EXPR SSA_NAME to be used as init during scev if possible, instead of the original one, and furthermore I believe extract_range_from_assert_expr should do a better job.
