[libdispatch-dev] lib dispatch worker threads may loop depending on compiler optimization

[Daniel A. Steffen]

On Sep 9, 2011, at 10:30 AM, Paolo Bonzini wrote:

> On 09/09/2011 05:49 PM, Dave Zarzycki wrote:
>>>> No, it didn't.  Really, believe me, unlike you I can follow GCC
>>>> development.;)
>> 
>> If putting asm("" ::: "memory") before __sync_lock_test_and_set()
>> fixes the bug, then that proves that GCC no longer considers
>> __sync_lock_test_and_set() to be a full barrier.
> 
> It is not "no longer".  It never did, and it worked by chance.
> 
> It doesn't even consider it an acquire barrier, in fact.  Even for a cmpxchg or any other sync builtin, the barrier semantics remain in the assembly, but are lost for the compiler midway through the compilation.

that loss sounds like a clear bug in GCC to me (it doesn't make sense for the __sync builtins not to be compiler barriers given that they are defined to generate memory barrier instructions), is there a reference to this issue that we can track ?

Daniel