Re: optimization/7557: gcc-3.1.1 (debian/i386): wrong code with -O2 / bitfields / pointer aliasing

Re: optimization/7557: gcc-3.1.1 (debian/i386): wrong code with -O2 / bitfields / pointer aliasing

[Robert Dewar]

> 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
optimization.

Re: optimization/7557: gcc-3.1.1 (debian/i386): wrong code with -O2 / bitfields / pointer aliasing

[Johannes Stezenbach]

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
> optimization.

I am not against including -fstrict-aliasing in -O2. I like
good optimization.

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.


Regards,
Johannes

PATCH for Re: optimization/7557: gcc-3.1.1 (debian/i386): wrong codewith -O2 / bitfields / pointer aliasing

[Gerald Pfeifer]

On Tue, 13 Aug 2002, Johannes Stezenbach wrote:
> I am not against including -fstrict-aliasing in -O2. I like
> good optimization.
> [...]
>
> Please consider adding a note to NEWS and/or
> http://gcc.gnu.org/gcc-3.0/caveats.html or a similar document.

Done.

Gerald

Index: caveats.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.0/caveats.html,v
retrieving revision 1.5
diff -u -3 -p -r1.5 caveats.html
--- caveats.html	23 Jan 2002 15:42:27 -0000	1.5
+++ caveats.html	14 Aug 2002 07:48:32 -0000
@@ -8,6 +8,13 @@
 <h1>GCC 3.0 Caveats</h1>

 <ul>
+  <li><code>-fstrict-aliasing</code> is now part of <code>-O2</code>
+  and higher optimization levels.  This allows the compiler to assume
+  the strictest aliasing rules applicable to the language being
+  compiled.  For C and C++, this activates optimizations based on the
+  type of expressions.  This optimization may thus break old,
+  non-compliant code.
+
   <li>Enumerations are now properly promoted to <code>int</code> in
   function parameters and function returns.  Normally this change is
   not visible, but when using <code>-fshort-enums</code> this is an

Re: optimization/7557: gcc-3.1.1 (debian/i386): wrong code with -O2 / bitfields / pointer aliasing

[Johannes Stezenbach]

On Tue, Aug 13, 2002 at 01:00:03PM -0400, Robert Dewar wrote:
> Well such a warning could certainly go in the documentation, but surely you
> are not suggesting that every time someone does a compilation with -O2 that
> a junk warning be issued?

;-)
No, of course not.

Johannes

Re: optimization/7557: gcc-3.1.1 (debian/i386): wrong code with -O2 / bitfields / pointer aliasing

[Robert Dewar]

<<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.
>>

Well such a warning could certainly go in the documentation, but surely you
are not suggesting that every time someone does a compilation with -O2 that
a junk warning be issued?

(the compiler cannot of course detect cases where there is a problem, that's
the whole point of the aliasing rules)

Re: optimization/7557: gcc-3.1.1 (debian/i386): wrong code with -O2 / bitfields / pointer aliasing

[Johannes Stezenbach]

On Fri, Aug 09, 2002 at 07:05:00PM -0000, sirl@gcc.gnu.org wrote:
>     You have written undefined C code (hint: the compiler is
>     free to assume that fs, *f and *p are diffrent objects),
>     either fixup your code or compile with -fno-strict-aliasing.
> 
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7557

Thanks for the info, I now read the documentation about
gcc's -fstrict-aliasing and the 'restrict' type qualifier in C99,
http://www.lysator.liu.se/c/restrict.html .

But I was unaware that -O2 implies -fstrict-aliasing in gcc-3.1.
It did not in gcc-2.95.3, and the only hint I found was in the
NEWS file for gcc-2.95.3:

   The -fstrict-aliasing is not enabled by default for GCC 2.95.2. While
   the optimizations performed by -fstrict-aliasing are valid according
   to the C and C++ standards, the optimization have caused some
   problems, particularly with old non-conforming code.

The old non-conforming code did not likely go away, and
unknowing people like me still write new non-conforming code.

Please do your gcc users a favor and consider adding a warning to the
(not yet exisiting) caveats page for gcc-3.1, or gcc-3.0,
http://gcc.gnu.org/gcc-3.0/caveats.html

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?


Regards,
Johannes