Re: Patch: New implementation of -Wstrict-aliasing

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

On Sun, 21 Jan 2007, Ian Lance Taylor wrote:

| Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| > True, the front-end has no capability to do flow analyzis, but no flow
| > analysis is really required in
| >
| >     int main()
| >     {
| >       float f = 0;
| >       return *(int*)&f;
| >     }
| >
| > to determine that "*(int*)&f is not recommended.
| >
| > The point is this: not all of the cases that can be warn about require
| > proper data flow analysis.  Those cases should be handled by the
| > front-end.
| >
| > Unless I'm misundestand your explanation, you seem to argue as if this
| > is a "all-or-nothing" thing.  But it is not.  And that is not theory.
|
| It is likely that either you or I misunderstood.  I don't object to
| issuing a warning about that case in the front end.
|
| You originally said:
|
| >   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.
|
| Implementing the above in the front-end is not that.  Your example is
| more like implementing the core of the aliasing warning in the
| middle-end, and handling the trivial cases in the front-ends.  That is
| fine with me.

Great.

| In particular, if we keep part of the warning in the front-ends, I
| believe we should eliminate the false positives.

Yes.

| Your example is not
| a false positive, of course, but the current warnings have many false
| positives.

<nod>

| It is easy to modify the warnings to eliminate the false
| positives; of course one effect will be to increase the number of
| false negatives.

So, here is my suggested plan:
  (1) have the front-ends handle the "easy" cases;
  (2) fancier constructs needs more analysis, therefore only
      middle-end capabilities can tell -- I'm fine with that.

-- Gaby