Jim Meyering wrote: > Thomas Rast wrote: > > Jim Meyering wrote: > >> Thomas Rast wrote: > >> > [GCC moves access to a file-static variable across pthread_mutex_lock()] > >> > >> Thanks for the investigation. > >> Actually, isn't gcc -O2's code-motion justified? > >> While we *know* that those globals may be modified asynchronously, > >> builtin/grep.c forgot to tell gcc about that. > > > > I'm somewhat unwilling to believe that: > > You're right to be skeptical. > I should have stuck with "using volatile works around the problem for me". > The real problem seems to be in glibc, with its addition of > the "leaf" attribute to those synchronization primitives: > > http://bugzilla.redhat.com/747377#c22 Aha. Glad you found it :-) Meanwhile I read http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html which discusses a similar issue in section 4.3, but is very interesting on its own. It's funny how it says We know of at least three optimizing compilers (two of them production compilers) that performed this transformation at some point during their lifetime; usually at least partially reversing the decision when the implications on multi-threaded code became known. I guess that would be four now if it was literally the same problem. -- Thomas Rast trast@{inf,student}.ethz.ch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html