http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
Dmitry Vyukov <dvyukov at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dvyukov at google dot com
--- Comment #16 from Dmitry Vyukov <dvyukov at google dot com> ---
(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.
Data races do not work this way. It's undefined behavior:
http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
The code must use relaxed atomic load. If the code becomes slower due to that
then:
(1) the current generated code is incorrect
or (2) there is a performance bug in gcc handling of atomic operations
