This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
- From: "tg at mirbsd dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Jan 2007 03:39:51 -0000
- Subject: [Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
- References: <bug-30477-13924@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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