Re: Patch: New implementation of -Wstrict-aliasing

[Ian Lance Taylor <iant at google dot com>]

Gabriel Dos Reis <gdr@cs.tamu.edu> writes:

>    I tend to believe that we should NOT emit warning from middle-end,
> but I also appreciate that some warnings are just impossible to emit
> from the front-end.  Consequently, my general sentiment is to *prefer*
> warnings from the front-ends (90%), and tolerate the 10% when it is
> necessary. 
> 
>   For your specific patch, I would like to see the core of the
> aliasing warning remain in the C and C++ front-ends, and handle the
> additional tricky places in the middle-ends.

I believe that this warning is an example of those which can not be
emitted from the frontends.

The core idea here is to warn about code which gcc is going to compile
in an unexpected way.  Doing this requires a flow sensitive analysis
of when a pointer with one type is used to access an object of a
different type.  The frontend has no ability to do flow sensitive
analysis, and the frontend has no knowlege about alias information,
and it makes no sense to add this knowledge to the frontend.

Moving the warning into the frontend will imply bulking up the
frontend considerably in order to avoid both false positives and false
negatives.  I think that would be ill-advised.  We need more than a
theoretical reason to do that.


I also want to say that in my experience the current front-end
aliasing warnings are worse than useless.  They have some false
positives and many false negatives.  I am definitely in favor of
removing them.  Warnings with both false positives and false negatives
are more harmful than useful.

Ian