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

[Johannes Stezenbach <js at convergence dot de>]

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