From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6516 invoked by alias); 20 Apr 2010 20:44:05 -0000 Received: (qmail 5927 invoked by uid 48); 20 Apr 2010 20:43:47 -0000 Date: Tue, 20 Apr 2010 20:44:00 -0000 Message-ID: <20100420204347.5926.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/43680] [DR 1022] G++ is too aggressive in optimizing away bounds checking with enums In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mmitchel at gcc dot gnu dot org" 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-04/txt/msg02112.txt.bz2 ------- Comment #13 from mmitchel at gcc dot gnu dot org 2010-04-20 20:43 ------- I think this optimization is valuable in some cases, so I think this is a question of defaults, rather than of behavior per se. While it may be useful for some security-related applications not to eliminate the checks, but it is clearly useful in other contexts to eliminate the checks. "Optimizing away bounds checking" is certainly not in and of itself a bug. In some sense, this is similar to strict-aliasing, or signed-does-not-overflow optimization. There's a lot of code out there that depends on something that's not portable. It's not useful to break that code, but it is useful to be able to optimize. (One case where I think this optimization is likely to be valuable is in switch/if statements where you're cascading through values; this optimization can allow you to eliminate the catch-all case at the end, which is certainly a win for code-size.) I think the standard should say that you get an indeterminate value when you convert an out-or-range input to an enum (and that such value may be outside the bounds of the enum range), but that the program is not allowed to go and reformat your disk. Ada has a notion of errors like this; the damage is bounded. This doesn't need to be in the dereference NULL pointer category of behavior, but neither should it have any guaranteed semantics, including that the value is masked down. So, I think we should have a C++ front-end option that says "interpret enums strictly". I think it should be off by default for compatibility with existing code. -- mmitchel at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmitchel at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680