gcc3 vs 176.gcc

[Joe Buck]

I wrote:

> > The idea: we have a pointer of type T1, and there is a dereference
> > based on a casted-to-T2 form of that pointer, where T1 and T2 aren't
> > compatible types for the purpose of the aliasing rule.  For example
> > 	T1 * p;
> > 	...
> > 	*((T2 *)p = value;
> > or
> > 	((T2 *)p)[expression] = value;
> > (or alternatively a read).  The key is that the pointer is converted
> > to an incompatible type, and then dereferenced, possibly after adding
> > an offset.
> 
> Such code does not necessarily violate the aliasing rules - unless the
> same object is accessed in both types.  If alignment permits, it is valid
> (albeit bad style) for the pointer to be stored as type T1 *, but the only
> accesses through it being of objects of type T2.  So the warning should
> only be if we prove the accesses to access the same byte, while type-based
> aliasing says they don't conflict.

I disagree.  It is perfectly legitimate to issue warnings for code that
are legal ISO C but hopelessly bad style.  It would be wild obfuscation to
declare a pointer of type T1 but only initialize it with references to
objects of type T2 in all possible control flows, other than in cases
where T1 is (const,volatile,etc) char* or void* and the aliasing rules
treat these as special already.

We could only do the proofs you ask for with a global dataflow analysis
(crossing function boundaries), and this is not feasible.

Something like

warning: access to object of type `T1' as type `T2' violates ISO C: consider using unions