This is the mail archive of the gcc-patches@gcc.gnu.org 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, SPU] Fix PR47179 (Re: [PATCH] Prepare for a fix for PR47179)


On Tue, 18 Jan 2011, Ulrich Weigand wrote:

> Richard Guenther wrote:
> > On Tue, 18 Jan 2011, Ulrich Weigand wrote:
> > > + 
> > > +   if (DECL_P (base)
> > 
> > TREE_CODE (base) == VAR_DECL
> > 
> > > +       && !TREE_STATIC (base)
> > 
> > As you are checking for a RECORD_TYPE you need to exclude auto-variables
> > like with
> > 
> > 	  && DECL_EXTERNAL (base)
> 
> OK, done.
> 
> > > +       && TREE_CODE (TREE_TYPE (base)) == RECORD_TYPE)
> > > +     return true;
> > > + 
> > > +   return default_ref_may_alias_errno (ref);
> > 
> > I think you can safely remove the default_ref_may_alias_errno call
> > and return false.
> 
> I left it in since there may be some who use SPU with a different
> libc than newlib -- if we'd *only* expect _impure_data here,
> other libcs will probably break ...
> 
> > Btw, you could match the DECL_ASSEMBLER_NAME with _impure_data
> > (newlib is not thread safe?) and even match the offset of the
> > errno member if you like (ao_ref_offset (ref)).
> 
> SPU is always single-threaded.  The use of _impure_data is just
> to avoid having to make major changes to common newlib code,
> which expects all its "globals" to be in such a structure to
> allow for thread safety on platforms that *are* multi-threaded ...
> 
> I can try matching the DECL_ASSEMBLER_NAME; I guess the _impure_data
> name is now part of the ABI anyway.  I was unable to find any function
> called ao_ref_offset, however ... am I missing something?

I did.  It's simply ref->offset, valid after ao_ref_base has been called.

Richard.


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