gcc3 vs 176.gcc

[Joe Buck]

> > From: Joe Buck <jbuck@synopsys.com>
> > Date: Wed, 9 Jan 2002 12:44:19 -0800 (PST)
> > Cc: rth@redhat.com (Richard Henderson), geoffk@redhat.com (Geoff Keating),
> >         dalej@apple.com (Dale Johannesen), gcc@gcc.gnu.org
> > 
> > I wrote:
> > 
> > > I think that the check happens too late if it is done this way.
> > > Better to detect that the rules are broken at the time of tree->RTL
> > > conversion.  In the 176.gcc case, as soon as we parse
> > > 
> > > 	((int *)rt)[length]
> > > 
> > > and note that the type of rt is not pointer to (possibly cv-qualified)
> > > int or unsigned, we know already that the rules have been broken,
> > > independent of what the backend is.
> > 
> > What if we tell the back end that such a pointer expression (one that
> > breaks the rules) is a pointer to char*, or aliases like one? (can
> > collide with anything)?
> 
> The problem is finding which expressions break the rules.  What I
> expect will happen is that we can do a 90% solution, but the missing
> 10% will vary by target and compiler revision---some things will work
> on x86 with 3.1, some of those won't work on powerpc, and some won't
> work with 3.2.  So you end up with a 70% or 30% or 5% solution.

I guess I'm still not seeing it: I would flag certain cases in the front
end, where we are still back-end independent.  Then we only have to make
sure that any annotations get preserved by the backends.

> A much better project, one which has been waiting for someone to do it
> for some time and is universally agreed to be a good idea, is to have
> the compiler warn in situations where it detects that the rules are
> broken.

There are two ways of detecting it: based on offsets against registers
(which would exist only in some back ends), or based on types of pointers
closer to the source.  The latter type of check would work on all targets.