gcc3 vs 176.gcc

[Joe Buck]

> On Wed, 9 Jan 2002, Joe Buck wrote:
> 
> > We could only do the proofs you ask for with a global dataflow analysis
> > (crossing function boundaries), and this is not feasible.
> 
> The original report of the problem with SPEC claimed that in the case in
> question a local examination of two insns suffices.

Nope.  You asked for a proof that the aliasing rules are being violated.
Examination of the two insns reveals that the same location is being
accessed twice, it says nothing about whether this is a legal alias or
a violation of ISO C.

> > Something like
> > 
> > warning: access to object of type `T1' as type `T2' violates ISO C: consider using unions
> 
> What does "of type `T1'" mean here?  Declared type, or effective type?  
> Without dataflow analysis, we know neither type of the object, only the
> type of a pointer to it.

The vagueness is deliberate to cover multiple cases.

In practice, it makes little difference.  There are three possibilities,
any of which deserves a diagnostic:

1) the real type of the object is compatible with T1, and it is being accessed
   as T2.  ISO C violation.

2) the real type of the object is compatible with T2, so we would have an
   ISO C violation at a different point if the original pointer is ever
   dereferenced.  Bad, obfuscated style and a bug just waiting to happen.

3) the real type is an array of char.  Again, if accesses take place
   through both the casted and uncasted pointers, we have an ISO C violation,
   so this is a bug just waiting to happen.