------- Comment #16 from tony3 at GarlandConsulting dot us 2010-01-27 20:39 ------- Your analogy is helpful, but a bit like comparing apples with oranges. The reason being that the compiler executes integer overflow loops identically for all optimization settings.
The following program compiles without warning at all optimization levels and executes as a forever loop in all cases: #include <stdio.h> main() { for (unsigned char i = 1 ; i <= 255 ; i++) { printf( "%d ", i); } } This example supports my point that the compiler ought not to silently convert an exiting loop into a forever loop based on optimizer settings because in this case it consistently operates the same--and testing will be sure to catch it if it is unintended. Having now given up on trying to convince the gcc folks that enumeration testing would be greatly facilitated by extending the allowable comparison range by 1 (in both directions), my point has reduced itself to saying that the compiler is essentially whimsical and unpredictable in that code that runs as expected 99% of the time becomes an infinite loop without warning in the 1% case. This is not what happens with integer overflow. I submit that if the above integer example operated like enumerations--causing a terminated loop 99% of time but converting to a forever loop at -O2, then the compiler would have been modified long ago because lots more people would have been tripped up by it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810