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

["tg at mirbsd dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #3 from tg at mirbsd dot org  2007-01-16 02:33 -------
Subject: Re:  Integer Overflow detection code optimised away,
 -fwrapv broken

Andrew Pinski (pinskia at gcc dot gnu dot org) dixit:

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

>Fixed in 4.0.0, 3.4.x is no longer being maintained by the FSF and has not for
>a while now.

>If you don't want to move to a newer GCC, that is your issue.

Interesting. So that basically means that, while you are publically
admitting that you wrote the (faulty, from a security and pragmatic
point of view) optimisation code, you are not willing to provide an
instruction to disable it just because gcc 3.4 is no longer suppor-
ted, and try to coerce us into "upgrading", whileâ?¦

>Also why should we support older GCC when we can barrely support the current
>ones?

â?¦ you're publically stating, in the same PR that you can't even get
current versions of gcc to perform correctly and produce sane code?

I think this is a very poor attitude of yours. If someone adds code
doing a possibly unsafe optimisation he usually also adds a flag to
disable that certain optimisation. You didn't do this when breaking
gcc in the past. It's a shame that this was only discovered recent-
ly, especially due to security considerations. 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"?

>         Resolution|                            |FIXED

Is this a practical joke or what? I specifically did *not* open the
bug report against gcc4. You people should know better than to tell
users to test incremental diffs of what happened between 3.4 and 4,
because I've never seen a gcc developer who didn't talk of that new
version of a "major change".

Especially you as the author of code in question could probably put
together a patch which solves the problem for gcc 3.4.6, the latest
one of the affected series; interested parties could back-port this
to other versions then.

¹) I know of at least qemu - there are probably many more. 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.

For what it's worth: I'm writing as developer of the MirOS Project,
but I am also a developer of FreeWRT, an embedded GNU/Linux distri-
bution kit which is used by the president of the FSF Europe, and it
*also* uses gcc 3.x on most platforms because upgrading simply *IS*
*NOT* *POSSIBLE*.

I sincerely hope some other developer reading this will have a dif-
ferent position on this topic. Otherwise, the GCC steering commitee
might have bad public relations in a not-so-far future.

Sincerely,
//mirabile


-- 


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