Re: type based aliasing again

[Mark Mitchell <mark at codesourcery dot com>]

Someone (not RMS, but I have lost track of who, originally) wrote:

    In the end, if your argument is carried too far, the
    only solution would be to make -fno-strict-alias the
    default.

I think that making -fno-strict-aliasing the default is sensible
proposal, and worth debating.

Whether or not it is the default should be based on a variety of
considerations, including how many programs are "broken" by the more
correct behavior, how many of those can and will be easily fixed, and
how many are actively maintained.

For example, the Linux kernel is not a good reason to change the
default; it is easy for this actively maintained project to simply add
-fno-strict-aliasing to their Makefiles, if appropriate.  But, if it
is true that most, or at least a lot, of programs do not follow the
ISO rules, then it may be that we have set the default incorrectly.
In my experience, there are not too many such programs; I have only
seen one such cases in our customer's code, and that was very easily
fixed.  However, I make no claim that this code base is reprsentative
of things compiled with GCC.

I would much rather see us change the default, if that is really
necessary, than muddy the waters with confusing semantics, semantics
that will change due to minor adjustments to the compiler.  Yes, this
would mean that users cannot have their cake and eat it too: they
cannot have the benefits of -fstrict-alaising and still not follow the
ISO rules.  But, they are no worse off than before we added the
aliasing optimizations.

The best strategy at this point, in my opinion, would be for someone
to implement the warning.  (Note that this is non-trivial.)  Then, we
can get some idea as to how much code is breaking the rules, and then
judge whether or not he default is correct.  We must also weigh the
risk that people will not fix the code, unless we break it, and that
we will therefore never be able to make -fstrict-aliasing the default.

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