Re: aliasing warnings [patch]

[Mark Mitchell <mark at codesourcery dot com>]

I expect your patch will be useful to some people.  Good work!

As for printing type-names, it's too bad we don't force every language
front-end to provide an interface to do this.  In C++, we have
`type_as_string' for this purpose, but there's no interface to get at
it from the middle-end.

I looked at a few of the warnings that were generated with GCC this
way.  I was not surprised to see that all of them (in my spot check of
five or six) were false positives of the same form: a pointer is cast
to a different type, but then uncast before it is used.  Your patch
causes us to warn in both places.  For example, SAVE_EXPR_RTL stores
an `struct rtx_def *' as `union tree_node *'.  I believe casts among
unrelated pointer types are implementation-defined, rather than
undefined, behavior, so long as you do not dereference them the wrong
way.  Such usage is not strictly portable, of course; implementations
are allowed to use different numbers of bits for different pointers.
So, the warning is a *little* bit useful even here.  Suffice it to say
that a machine that really didn't allow casting amongs unrelated
pointer types would break a ton more software than -fstrict-aliasing,
though.  In other words, I don't think we should worry about fixing
GCC to avoid these warnings, providing we're not dereferencing the
pointers incorrectly.

I think you should say:

  warning: dereferencing the result of pointer cast may ...

rather than `pointer cast may' since the cast is not really the
problem; it's using the cast pointer.

You shouldn't use `pedwarn' because C++ sets pedantic_errors, and so
programs will not compile.  Just do `if (pedantic) warning ()'.

I don't think this warning should be on by default; it's going to
generate a ton of false positives.  Probably many more than the RMS
proposal would.  And, I don't see how to get line-number information
for the RMS proposal.  I do think this warning might help interested
parties track down problems in their software, and thereby help to
avoid getting bitten by -fstrict-aliasing.

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