From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15312 invoked by alias); 19 Dec 2006 14:30:47 -0000 Received: (qmail 15282 invoked by uid 48); 19 Dec 2006 14:30:34 -0000 Date: Tue, 19 Dec 2006 14:30:00 -0000 Message-ID: <20061219143034.15281.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/30245] -O2 generates bad code In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dberlin 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: 2006-12/txt/msg01592.txt.bz2 ------- Comment #8 from dberlin at gcc dot gnu dot org 2006-12-19 14:30 ------- > > Is it reasonable and prudent to have tests like "if (n == 0)" > optimised away at the -O2 optimisation level ? > Yes > We should remember that -O2 is heavily used by lots of > customers. And they expect a lot from our optimizers. > > Some customers might argue that the old behaviour was fine at > -O2 and such a tense optimisation should only be available at > higher optimisation levels or moved into a special flag that the > user can set if they want to from the command line. The problem is that this "old behavior" is simply "luck". You are simply *lucky* the optimizer wasn't smart enough to remove the check in all cases. Now it is. > > There is a clear tradeoff here. If the new behaviour remains, > I suspect the flag -fwrapv will be a popular flag ;-> We have and will continue to optimize based on what the standard says we can do, and provide users flags to do otherwise. You want to do otherwise, so please use the flags. -- dberlin at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30245