This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
- From: "tony3 at GarlandConsulting dot us" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 27 Jan 2010 20:39:53 -0000
- Subject: [Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
- References: <bug-42810-18694@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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