Re: Patch: New implementation of -Wstrict-aliasing

[Gabriel Dos Reis <gdr at cs dot tamu dot edu>]

Silvius Rus <rus@google.com> writes:

[...]

| I have thought about leaving the warning in the front-end (perhaps
| improving a little on the current implementation) and use a different
| option level for the one in the backend.  Including your review, I
| have got three reasons for keeping it in the frontend:
| 1. You get some warnings at -O0.
| 2. You get warnings about the original source rather than after
| transformations such as folding.  Even if GCC happens to fix
| nonstandard code, users should be warned just in case GCC changes or
| they use other compilers.
| 3. You might be able to generate better warnings because you have
| direct access to language specific information.  In my experience,
| users got frustrated by two types of warnings: false positive and
| vague descriptions.
| 
| My reason for removing it from the frontend was:
| 1. Tried to keep it in just one place for simplicity.
| 2. It is hard to detect false positives in the front end.

Hi Silvius,

   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.

| Let me know what you think of this:
| Keep the current check in the front-end, but give it two flavors:
| 1. Only warn when the converted pointer is dereferenced immediately:
| *(int*)&float_var.
| 2. The original, which warns even if it is not dereferenced:
| (int*)&float_var.
| One of the two versions would be selected based on the value of
| --param wstrict-aliasing-accuracy.  I would go for version 1 included
| by default, because 2 gives false positives.

The aliasing warning is less of the compiler internals tinkering than
general statements about user codes, so the use of --param is
inappropriate.  If necessary, please consider extending 
-Wstrict-aliasing to take an argument, e.g.

   -Wstrict-aliasing=level

with

   -Wstrict-aliasing

equivalent to

   -Wstrict-aliasing=default-level

-- Gaby