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++
