[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken

["pinskia at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]



------- Comment #4 from pinskia at gmail dot com  2007-01-16 03:04 -------
Subject: Re:  Integer Overflow detection code optimised away,
        -fwrapv broken

On Tue, 2007-01-16 at 02:33 +0000, tg at mirbsd dot org wrote:
> The real shame is an
> attitude of "we won't fix it, either use -O0, or upgrade to current
> versions of gcc, which, by the way, are poorly supported and do not
> compile existing¹ programmes correctly at all"? 

If you consider 4.0.x a current version of GCC, you must be joking, it
was released on "April 20, 2005" almost 2 years ago.


> I specifically did *not* open the bug report against gcc4.
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
to fix a bug in a release branch who's first release was almost three
years ago (FireFox 1.0.x for an example)?  Do you support a release
branch product for three years since you are a person who supports an
OS.  I doubt that you do.  I know of only one project who supports an
release branch for longer debian (5 years or so) and the developers of
debian actually contribute to GCC also and they are able to figure out
what patches they need to backport.  

So how long do you support a release branch of your OS?


> I know of at least qemu
Then fix qemu; x86 has not many registers so it is very easy to get into
a case where inline-asm breaks.



> > Also why should we support older GCC when we can barrely support the
> > current ones?
As for this comment, I was more talking about the bugs which are minor
or don't effect major targets or even bugs which are not even
regressions.

> Especially you as the author of code in question
I did not write this code, I just know of it.


> Besides,
>    upgrading gcc involves upgrading g++ which is a PITA, despite it
>    being an "improvement of adhering to the language specification"
>    this BREAKS EXISTING CODE. Not everyone can afford this.

And we get request from users for fixing g++ to adhere to the language
standard;  I can name a few bugs which were not filed by a GCC developer
but would break existing code (and ones which were fixed did that).
So it is a trade off, break existing code or go by the standard.  We
decided it is better to go by the standard and hope people's code is
actually standards based code.  This is the problem with C/C++ right now
is that people don't write standards based code, unlike say Ada, Fortran
(which most do or with very well known extensions) and Java (which is
not officially standardized but there is a specification).  C/C++ are
being taught as if it is not a standardized language and there is not a
specification for it and people don't use specs as a reference.



Thanks,
Andrew Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477