Re: Linux and aliasing?

[mark at codesourcery dot com]

I don't think the cast rule is by any means the right obvious default.
For one thing, it pessimizes object-oriented C code that does
downcasts through an inheritance hierarchy.  There's no reason that we
shouldn't be able to use type-based alias analysis in such situations,
but your proposal would make it not happen.

You can use -fno-strict-aliasing to get the "traditional" behavior.
The only affect on your code will be that some optimizations that used
not to happen, but would with -fstrict-aliasing, will still not
happen.  What's the big deal?  If -fstrict-aliasing had never been
implemented, you wouldn't be complaining would you?  So, we've
improved GCC, and we've preserved the old behavior.

GCC has plenty of odd rules and way too many options.  We don't need
more.  The exception, I think, is when there's something that you can
only do with a language extension or special flag.  Extended asm's are
one such; you just can't do it without an extension.  So, we have it.

But, here, you just don't like ANSI/ISO C, and wish it had different
semantics.  You *could* express what you want in legal ANSI/ISO C, and
then GCC would do the right thing, with its default flags.

If we come up with a rule that turns off strict aliasing only for code
which is non legal ANSI/ISO C, then perhaps we should issue a warning
(on the illegal construct) and then turn off strict aliasing.  But, I
don't think you should expect us to do this any time soon (without 
financial incentive, or a noble volunteer).

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com