https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102983
--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> --- This is a bit more interesting. The IL starts the pass as <bb 5> : if (c_3 < b_4) goto <bb 6>; [INV] else goto <bb 9>; [INV] <bb 6> : if (c_3 != 0) goto <bb 7>; [INV] else goto <bb 8>; [INV] <...> <bb 11> : # c_3 = PHI <0(2), c_2(10)> # b_4 = PHI <0(2), b_16(10)> if (b_4 <= 0) goto <bb 3>; [INV] else goto <bb 12>; [INV] so the initial condition is "if (c_3 < b_4)" the initial attempt to calculate c_3 = PHI flows along and uses a value of b_4 determined by loop analysis of [0,1]. (we haven't gotten to propagating b_4 along the back edges yet) so it ends up deciding c_3 has a range of [-INF, 1] We then plod along, and eventually handle b_4, and propagate that b_4 is [0,0[ on the edge 11->3. There is no direct dependency between c_3 and b_4, so there are no values going stale due to this updated value. Meanwhile, we eventually visit the if (c_3 < b_4) stmt, and b_4 is known to be 0, so the simplifier changes this to if (c_3 < 0). Ranger however, doesnt know this was simplified, and at the moment doesn't think it needs to recalculate any outgoing ranges and update on-entry cache values in successor blocks. It dDoesn't realize there is a reason to recalculate it. Whenever we successfully fold or simplify a conditional, we probably need to check if any values should then be propagated. I believe that it will happen automatically for anything that is defined by the statement due to the nature of the temporal cache. Statements like GIMPLE_COND which have no LHS have no triggers.