http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Joost.VandeVondele at mat dot
ethz
| |.ch
--- Comment #14 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch>
---
(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, 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 ?
