This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc3 vs 176.gcc
- From: Joe Buck <jbuck at synopsys dot COM>
- To: jsm28 at cam dot ac dot uk (Joseph S. Myers)
- Cc: jbuck at synopsys dot COM (Joe Buck), dewar at gnat dot com, aj at suse dot de,dalej at apple dot com, gcc at gcc dot gnu dot org
- Date: Wed, 9 Jan 2002 13:22:42 -0800 (PST)
- Subject: Re: gcc3 vs 176.gcc
> 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.