This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][java] Fix type problems in the Java frontend

Richard Guenther writes:
 > On Thu, 12 Jul 2007, Andrew Haley wrote:
 > > Tom Tromey writes:
 > >  > >>>>> "Richard" == Richard Guenther <> writes:
 > >  > 
 > >  > Richard> (It looks like there is funny stuff going on in the FE - it does
 > >  > Richard> the equivalent of *(T **)p with p of type (T *).  This may ask for
 > >  > Richard> trouble with aliasing.)
 > >  > 
 > >  > Yeah, there are some oddities with types.  I don't recall this one
 > >  > offhand.  Could you file it?  Or update the existing gcj "types are
 > >  > weird" PR with more info?
 > > 
 > > My understanding is we are perfectly entitled to do this in the front
 > > end.  If C's aliasing rules (which, of course, only apply to C and
 > > C++) are to be enforced with GIMPLE then I need a clear statement of
 > > the fact, along with rules about exactly what I am allowed to do in
 > > the front-end.
 > It is the front-ends business to make sure to tell the middle end
 > that for the above case (T *) and (T **) alias (if the pointer p
 > above is ever dereferenced without casting it to (T **) before - as
 > only mismatched accesses are troublesome, the pointer type itself
 > is of course not).  This is done through the usual way with the
 > get_alias_set langhook and recording proper conflicts.

Right, that's what I thought.  So, the alias sets are the
responsibility of the FE, and if we cast between pointers to different
alias sets that's a bug in the FE.  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]