This is the mail archive of the
mailing list for the GCC project.
Re: optimization/7557: gcc-3.1.1 (debian/i386): wrong code with -O2 / bitfields / pointer aliasing
- From: Johannes Stezenbach <js at convergence dot de>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: gcc-bugs at gcc dot gnu dot org, sirl at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Tue, 13 Aug 2002 18:51:47 +0200
- Subject: Re: optimization/7557: gcc-3.1.1 (debian/i386): wrong code with -O2 / bitfields / pointer aliasing
- References: <20020812220548.7462CF2D45@nile.gnat.com>
On Mon, Aug 12, 2002 at 06:05:48PM -0400, Robert Dewar wrote:
> > I wonder: Thousands of software packages use -O2 by default.
> > How many of them will fail mysteriously when compiled with gcc-3.1,
> > just because of the implied -fstrict-aliasing?
> Who knows? But it is just a special case of the general phenomenon that junk
> code which people get away with often falls foul of perfectly legitimate
> optimizations, and as compilers improve, such code fails.
> It is nice of GCC to provide facilities for keeping old junk code running (there
> is certainly no requirement for a C compiler to do so), but it seems clear that
> the default for the highest optimization level should be to take advantage
> of the aliasing rules, which are after all there *precisely* to enable effective
I am not against including -fstrict-aliasing in -O2. I like
But I think it would be a good idea to give out a warning that old
(or new) junk code will no longer work with gcc-3.x when compiled with -O2.
After all the old junk code will have to be changed (or at least
identified, so -fno-strict-aliasing can be used where necessary). And
that's much easier when you know what to look for.
Please consider adding a note to NEWS and/or
http://gcc.gnu.org/gcc-3.0/caveats.html or a similar document.
It might help some gcc users. It would have saved me some time hunting
a strange bug, and it would have saved you the time dealing with
an invalid bug report.