https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91475
--- Comment #2 from Eric Musser <eric_musser at yahoo dot com> --- But in this case the undefineness is not directly related to the for loop. Further the optimizer that changes the loop to maintain and compare j * 0x20000001 as opposed to just j could detect certain overflow as the upperbound for the loop is a constant (j < 9) -- since 9 * 0x20000001 > (1<<31). In this case the optimization could either be disabled or produce a warning. The fact the end-condition of the for loop is optimized away completely suggests this is not a runtime issue (the infinite loop is hardcoded into resulting assembly). In the case the upperbound of the for loop is variable I agree it is not possible to detect nor may it be worth disabling the optimization if there is only a chance of overflow.
