[Bug sanitizer/59215] tsan: warning in shared_ptr_base.h

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215

--- Comment #15 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Joost VandeVondele from comment #14)
> (In reply to Jonathan Wakely from comment #10)
> > No, you're right, that's a different issue.  I think we've just been relying
> > on loads of (correctly-aligned) _Atomic_word being atomic, although that's
> > not going to keep tsan happy!  There's no barrier on the read, but I think
> > the worst that will happen is we won't see the correct value and the CAS
> > loop will go round again. We won't see __count==0 spuriously, because once
> > that count reaches zero it never gets incremented again.
> 
> Interestingly, a very similar comment was made yesterday in the context of
> libgomp: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194#c4
> 
> If for performance reasons a plain load would nevertheless be preferred over
> an atomic one, 

Why would that be? relaxed atomic loads end up generating the same instructions 
as plain loads. 

> I wonder if these threading libraries could e.g. use
> conditional compilation such that, when compiled with -fsanitize=thread, an
> atomic load is used nevertheless. Does -fsanitize=thread define a
> __SANITIZE_THREAD_IN_USE or similar ?

In clang, tsan uses __has_feature(thread_sanitizer).

In gcc asan defines __SANITIZE_ADDRESS__, but I don't think we have 
__SANITIZE_THREAD__ and it would be very pity if we have to use it in libstdc++