This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]