Re: [Patch, toplevel/config] fix tls.m4 configure race condition (bootstrap/PR43170)

[IainS <developer at sandoe-acoustics dot co dot uk>]

On 8 Jun 2010, at 20:58, Ralf Wildenhues wrote:

> * IainS wrote on Tue, Jun 08, 2010 at 09:41:45PM CEST:
> > On 8 Jun 2010, at 20:21, Ralf Wildenhues wrote:
> > > * Jakub Jelinek wrote on Tue, Jun 08, 2010 at 09:15:57PM CEST:
> > > > The test is testing for a bug in old glibcs which was violating the
> > > > __thread property, and I believe you really need some optimization
> > > > barriers for the test, otherwise some smart optimization in the
> > > > future will optimize the test away and let it succeed on buggy old
> > > > glibcs.
> > >
> > > Thank you, finally we are getting somewhere!  I think this paragraph
> > > should be put in a comment before the test in tls.m4.
> >
> > as a suggestion:
> >
> > # The 'volatile' qualifier on the references coupled with the  
> > positioning of the
> > # reference to 'a' is necessary to achieve an optimization barrier  
> > for compilers
> > # using whole program or other advanced optimizations.
>
> Well, if it doesn't mention that this is really about an old glibc bug
> which caused the __thread property to be violated, then I would never
> understand why the test is written the way it is.  The glibc bug is  
> the
> crucial bit of information; the need to work around compiler
> optimization is only to ensure the test is effective in two  
> directions.
> I'd suggest something like:
>
>  dnl Test for an old glibc bug that violated the __thread property.
>  dnl Use volatile to ensure the compiler won't optimize away pointer
>  dnl accesses it might otherwise know to be different, or reorder them
>  dnl and reuse storage, which may let them point to the same location.

thanks, I've bootstrapped & checked for correct behavior on x86_64- 
darwin10
w/out the comment - I'll now put this in and re-config, bootstrap (on  
i686-darwin9) and re-post.
Hopefully later today.

thanks everyone for the input.
Iain