[Bug c/42907] -fstrict-aliasing breaks valid code

emn13+gcc at nerbonne dot org gcc-bugzilla@gcc.gnu.org
Mon Feb 1 10:16:00 GMT 2010



------- Comment #29 from emn13+gcc at nerbonne dot org  2010-02-01 10:16 -------
What's particularly unfortunate about this instance is the fact that gcc fails
to warn you about the erroneous code, despite the obvious signs and despite
-Wall.

Line 15 is obviously potentially problematic, but it doesn't show up as such
even when -Wall is used.  This means that any improvement in the optimizer
which causes it break similarly invalid code may be terribly hard to debug -
the code violates the spec, but there's just no hint that it's wrong (and
worse, it works fine when compiled with less optmization, such as for
debugging).

And additional factor here is that it's statically determinable that this code
will violate aliasing rules; line 15 creates an alias, and the next usage of
the variable is a write.  I realize that perhaps such read/write dependency
analysis isn't available at the time that warnings are normally output (I have
no idea about gcc innards), but that means that gcc is being presented with
code that raises a red flag (line 15), knowably violates the spec (line 22),
and yet doesn't even issue a warning even when compiled with -Wall.  That's
bound to make a gcc-users life hard, particularly as there's a bunch of old c
code lying around that's probably not entirely up-to-spec.

So, the OP's code is clearly at fault, but that doesn't necessarily mean gcc
couldn't do more to prevent this kind of error.


-- 

emn13+gcc at nerbonne dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |emn13+gcc at nerbonne dot
                   |                            |org


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



More information about the Gcc-bugs mailing list