From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3393 invoked by alias); 27 Jan 2010 22:25:10 -0000 Received: (qmail 3086 invoked by uid 48); 27 Jan 2010 22:24:49 -0000 Date: Wed, 27 Jan 2010 22:25:00 -0000 Message-ID: <20100127222449.3084.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out. In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "tony3 at GarlandConsulting dot us" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg03157.txt.bz2 ------- Comment #21 from tony3 at GarlandConsulting dot us 2010-01-27 22:24 ------- Thanks for that last example which does illustrate a condition where -O0 terminates and -O2 never does. So we've established there are other looping situations where the compiler does the same thing as in the enumeration examples above and converts a finite loop at -O0 to an infinite loop at -O2. So the enumeration behavior is not unique. But does that really establish that this what the compiler should do (I know it is "free to" do it, but should it)? Surely the bulk of programmers would find this surprising and disconcerting! Isn't it more likely to contribute to a serious failure in the field some day? Especially in situations where the enumeration values are well within an 8-bit quantity. In any event, I'm still wondering though about how similar in practice your example is to the enumeration situation? How much typical looping code is written as your example shows. In other words, it would be very rare to encounter in typical code. For one, you are not testing against a value at the top end of its defined range. I guess I don't have anything more to say by way of appeal other than this is one of those situations which may be "technically correct" and make some compiler implementers satisfied, but which will continue to trip up programmers who simply are trying to get something to work and are unaware of the dangers of combining enumeration range checks + enumeration values ending just before a power of two + -O2. Is it really true that providing a warning whenever a comparison results in an implied check against a value beyond the range of the native type would cause lots of grief for existing code? I guess I haven't seen situations where people make such comparisons and they don't expect them to work. Anyway, it seems clear I'm unable to make enough of a case to motivate gcc developers to consider changing the behavior of the compiler and we'll have to live with the situation. Thanks for your patience and explanations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810