https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I bet this is related to the uninitialized i. We have in bb3: # RANGE [0, 1] NONZERO 1 # i_57 = PHI <prephitmp_78(36), i_27(D)(2)> and in bb5: # RANGE [0, 1] NONZERO 1 # i_48 = PHI <i_57(4), prephitmp_78(34)> and in bb6: if (i_48 != 0) and in basic blocks dominated by the succ edges of bb6 uncprop replaces some 0s or 1s in phi with i_48. The value ranges ignore the uninitialized values, with the rationale that if the SSA_NAME is used somewhere, then in valid program it should be initialized. The problem here is that the if (i_48 != 0) comparison has been added artificially in the ch2 pass, hoisted before the condition that guarded its use. But at the point where the artificial i_48 != 0 is present even valid program can reach the point with uninitialized i and thus with the value range assumption violated. And then uncprop adds further uses of i_48, in places that are dominated by this artificial i_48 != 0, but aren't dominated by the original uses of i in the program. Not sure what can be done here though. Penalizing VRP by using always VARING for undefined values would probably slow down lots of code, not hoisting uses of partially undefined values is problematic, reverting the uncprop patch would be unfortunate.
