https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I think this is CCP's fault rather than VRP. Everything I've looked at in the vrp2 dump looks right to me. In the outer loop, h/i is # RANGE [irange] int [0, 3] NONZERO 0x3 # h_41 = PHI <h_21(8), 0(2)> # i_44 = PHI <i_43(8), i_19(D)(2)> and the second inner loop has _13 = (unsigned int) i_44; // This is before the second inner loop ... <bb 6> [local count: 304150043]: # i_42 = PHI <i_23(7), i_44(5)> _50 = (unsigned int) i_42; _17 = -_50; _34 = _13 - _50; # RANGE [irange] int [0, 2] NONZERO 0x3 h_40 = (int) _34; where i_23 = i_42 + -1; and # h_21 = PHI <h_40(6), 3(7)> Now, sure, i is uninitialized (the i_19(D) in PHI of the outer loop), but as has been discussed in the first loop a < h isn't true and so we don't use i there, and in the second loop d isn't NULL and so we don't i-- there either, but due to the function call we must reread the d value after each iteration. Which is the reason for the h_40 = (int) ((unsigned) i_44 - i_42) computation to get h when d is non-NULL in some iteration - if d is always NULL, it would be 3 in the PHI. But ccp4 goes wild on this, Visiting PHI node: i_44 = PHI <i_43(8), i_19(D)(2)> Argument #0 (8 -> 3 not executable) Argument #1 (2 -> 3 executable) i_19(D) Value: UNDEFINED PHI node value: UNDEFINED Lattice value changed to UNDEFINED. Adding SSA edges to worklist. ... Visiting statement: _13 = (unsigned int) i_44; which is likely UNDEFINED Lattice value changed to UNDEFINED. Adding SSA edges to worklist. ... Visiting statement: _50 = (unsigned int) i_42; which is likely UNDEFINED Lattice value changed to UNDEFINED. Adding SSA edges to worklist. ... Visiting statement: # RANGE [irange] int [0, 2] NONZERO 0x3 h_40 = (int) _34; which is likely UNDEFINED Lattice value changed to UNDEFINED. Adding SSA edges to worklist. etc., everything based on i is UNDEFINED. So, either our UNDEFINED handlingin CCP is incorrect, or we need to avoid creating that h_40 = (int) ((unsigned) i_44 - i_42) stuff in IVOPTS if it is based on uninitialized (but then, can't we get an uninitialized value propagated to it only after IVOPTS?).