This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/78158] Strange data race detection with thread sanitizer
- From: "torvald at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 21 Mar 2017 20:22:40 +0000
- Subject: [Bug sanitizer/78158] Strange data race detection with thread sanitizer
- Auto-submitted: auto-generated
- References: <bug-78158-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #19 from torvald at gcc dot gnu.org ---
(In reply to Dmitry Vyukov from comment #8)
> We need to modify tsan runtime to ignore (zero) __ATOMIC_HLE_ACQUIRE/RELEASE
> bits, right? It's only an optimization and we can pretend that elision never
> succeeds under tsan.
I agree. The actual memory order that callers have to provide in addition to
the HLE bits is what should determine the synchronization semantics.
(IMHO, exposing HLE instructions through memory order bits is a a weird
design.)