From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3591 invoked by alias); 16 Jan 2007 03:40:01 -0000 Received: (qmail 3558 invoked by alias); 16 Jan 2007 03:39:51 -0000 Date: Tue, 16 Jan 2007 03:40:00 -0000 Message-ID: <20070116033951.3557.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "tg at mirbsd dot de" 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: 2007-01/txt/msg01266.txt.bz2 ------- Comment #5 from tg at mirbsd dot de 2007-01-16 03:39 ------- Subject: Re: Integer Overflow detection code optimised away, -fwrapv broken pinskia at gmail dot com dixit: >If you consider 4.0.x I didn't say anything about 4.0, just gcc4 instead of gcc3. And many people (e.g. most embedded systems developers or persons with a large legacy codebase) just can't easily upgrade. >Right but 3.4.x is no longer maintained. This is like any other project >where old versions are no longer maintained. Ask for an example Mozilla Just that, in my opinion, core technology like especially gcc which changes over time (in contrast to binutils, where it pretty much doesn't matter if you upgrade) should be taken with a little bit more effort, especially if it's used by SO many people. >So how long do you support a release branch of your OS? We are two persons, thus, releases are more like snapshots that are especially stable. We do backport relevant changes if desired by users, though. >> Especially you as the author of code in question >I did not write this code, I just know of it. You did: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27257#c2 >So it is a trade off, break existing code or go by the standard. We I'm actually for "go by the standard", but, like I said, core technology, legacy codebase, should deserve a little bit more attention, especially if it's security relevant. Hey, I mean, is -fwrapv not actually supposed to counter this specific optimisation? bye, //mirabile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477