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: "jwakely dot gcc at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 Jan 2010 10:13:58 -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 #22 from jwakely dot gcc at gmail dot com 2010-01-28 10:13 -------
(In reply to comment #14)
>
> So does the C++ standard say that it is acceptable for the compiler to drop
> support for an out-of-range enumeration value in a way that the programmer has
> no idea it happens--but to support out-of-range enumeration values in other
> situations?
The standard says nothing about warnings, a program is either correct or not.
If it's not correct, the standard doesn't apply. The standard only defines
what happens if you stick to its rules. It can't possibly legislate what
happens if you go outside those rules, pretty much by definition.
> In other words, if gcc is so provably correct according to the standard in
> refusing to support an out-of-range-by-one enumeration value, why does it run
> the code at lesser optimization levels? Couldn't the fact that it runs the code
> without complaint in the majority of cases by considered a bug?
No. Undefined behaviour is undefined, not defined to behave consistently at all
optimisation levels.
I think a warning for this would be helpful, but asking for the compiler to
assume types can have values that they can't have is not a good idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810