Why is it different? "program hasn't done anything incorrect" includes not overflowing i. And being able to even put variables in register relies on such assumptions in a very similar as certain loop transformations rely on the assumption that the loop terminates before i overflows.
back
1 comments
The language should make it impossible to access x through the stack unless the programmer goes out of their way to perpetrate fraud. It's fair for the optimizer to assume that fraud hasn't been perpetrated.
If it's easy to overflow integer addition, then that must be regarded as an accident. Assuming absence of accidents is a poor default in ways that assuming the absence of fraud isn't.
First make it so that perpetrating integer overflow is inconvenient, so that the programmer has to go out of his way to request it. If that has been done, then sure, blindly assume that i + 1 is greater than i.
Integer overflow is relatively easy to detect and protect against at run-time using -fsanitize=signed-integer-overflow. (yes, needs testing. Doing it reliable at compile-time is hard.) But compilers also offer various options on how to deal with overflow. The users choose -O3 over other options. ISO C does not favor one over the other. But making it defined behavior that wraps would turn it into subtle correctness bugs which one can not easily screen for.
It's possible to just leave it undefined, without introducing unwarranted assumptions, such as that i + 1 is positive if i is positive, made in the absence of any assurance that i < INT_MAX.
That a computed expression i + 1 can be assumed to be positive for non-zero i follows mathematically from overflow being undefined.