This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug sanitizer/78158] Strange data race detection with thread sanitizer


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.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]