libsanitizer mege from upstream r169371

[Dmitry Vyukov]

http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_interface_atomic.cc?view=diff&r1=169378&r2=169379&pathrev=169379

We will integrate it later.

On Wed, Dec 5, 2012 at 5:03 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Yeah, but then there will be all that additional __sync_synchronize(),
> that are not needed if we use __atomic. And on the other hand, if we
> have that __sync_synchronize(), then we do not need __atomic...
>
> On Wed, Dec 5, 2012 at 4:57 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Wed, Dec 05, 2012 at 04:53:44PM +0400, Dmitry Vyukov wrote:
>>> On Wed, Dec 5, 2012 at 4:42 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>>> > On Wed, Dec 05, 2012 at 03:13:20PM +0400, Dmitry Vyukov wrote:
>>> >> I hope I addressed all your comments in this revision.
>>> >> I've fixed nand atomic operation, made atomic operations atomic again
>>> >> and added visibility attribute to interface functions.
>>> >
>>> > Mostly, still, __sync_lock_test_and_set isn't full barrier unlike most other
>>> > __sync_* builtins, so either you'd need to use __atomic_exchange_n if
>>> > available (you can e.g. guard it with #ifdef __ATOMIC_SEQ_CST), or
>>> > if not available also use __sync_synchronize ().
>>>
>>>
>>> __atomic_xxx are available since gcc 4.7 and we use gcc 4.4 on some
>>> bots. I do not want to clutter the code with macros too much.
>>
>> Well, one option would be just a single #ifdef somewhere,
>> #ifndef __ATOMIC_SEQ_CST
>> #define __ATOMIC_RELEASE 0
>> ...
>> #define __atomic_...(...) __sync_...(...)
>> ...
>> #endif
>> i.e. implement __atomic_* as macros using __sync_* if not available,
>> then just use __atomic_* in the code everywhere.
>>
>>         Jakub