https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512
--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> --- # e_25 = PHI <e_26(10)> _3 = e_25 + 1; if (_3 != 0) goto <bb 4>; [INV] else goto <bb 9>; [INV] <...> <bb 9> : # e_26 = PHI <e_27(D)(2), _3(3)> in order to take the edge 3->9, _3 must be [0,0]. _27 is used before defined, so we now use UNDEFINED for that. This allows the PHI to be folded to [0,0] This in turn feeds the PHI for e_25, and means e_25 must be [0,0] _3 is now confidently calculated as [0,0] + 1, making it [1,1] BUT. we just concluded that _3 must be [0,0] in order to feed the PHI, so ranger now decides that means _3 and e_26 are actually UNDEFINED.. which is true. This entire hunk of code is about to be removed, so we don't really need to do anything to it. However, the early VRP pass has concluded that since e_26 and _3 are constants, we can propagate the constant value. It does not consider UNDEFINED to be a constant value, so the propagation code was trapping because it had eliminated the definition of e_26, expecting it to be replaced with [0,0], not UNDEFINED. Probably the best way to fix this entire class of propagation errors is to do what we do with non-zero pointers. Once we get to a globally constant range where further refinements can only end up in an UNDEFINED state, stop further evaluating the range. This typically happens in places which are about to be removed by CFG cleanup anyway. Patch is in testing
