Thomas Rast wrote: ... >> 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. Yep. For those not following the BZ comments at the about URL, POSIX is quite clear. Quoting from http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11: The following functions synchronize memory with respect to other threads: fork pthread_barrier_wait pthread_cond_broadcast pthread_cond_signal pthread_cond_timedwait pthread_cond_wait pthread_create pthread_join pthread_mutex_lock pthread_mutex_timedlock pthread_mutex_trylock pthread_mutex_unlock pthread_spin_lock pthread_spin_trylock pthread_spin_unlock pthread_rwlock_rdlock pthread_rwlock_timedrdlock pthread_rwlock_timedwrlock pthread_rwlock_tryrdlock pthread_rwlock_trywrlock pthread_rwlock_unlock pthread_rwlock_wrlock sem_post sem_timedwait sem_trywait sem_wait semctl semop wait waitpid glibc's addition of the leaf attribute to any of those appears to make gcc violate that. -- 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