This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, toplevel/config] fix tls.m4 configure race condition (bootstrap/PR43170)
* Jakub Jelinek wrote on Tue, Jun 08, 2010 at 07:27:11PM CEST:
> On Tue, Jun 08, 2010 at 07:10:58PM +0200, Paolo Bonzini wrote:
> > >Is volatile required here because we want to peek behind implementation
> > >details that are not supposed to be observable, and observable features
> > >of threads don't need them?
> >
> > In "int volatile *volatile"
> > ^^^^^^^^ ^^^^^^^^
> > This one is to This one is probably superfluous.
> > ensure emutls You could also remove the * in
> > get_address is the second line.
> > called.
>
> The first volatile isn't needed. That affects accesses to a, but that is
> something that doesn't happen in the program at all.
>
> The second volatile is what might be needed (as alternative to making
> it a global) - to make sure a_in_main_thread = &a; isn't moved across the
> pthread_create call which for an automatic variable is possible
So, when we are admitting to the use of volatile as a hack to tame the
optimizer beast, let's turn the question around: does __thread have any
guaranteed observable semantics that we can test instead? I.e.,
something that doesn't need revisiting with the great optimizing
features of next year's GCC?
And no, I don't want to keep up the actual patch that started the
discussion; well, maybe a good comment at such a hack can't hurt.
Thanks everyone for the help!
Ralf