https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--- Comment #6 from Dmitry Vyukov ---
The real world situation is:
replace atomic_load/store implementation with relaxed atomic builtins here:
https://gcc.gnu.org/viewcvs/gcc/trunk/libsanitizer/sanitizer_common/sanitizer_atomic_clang_x86.h?view=m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--- Comment #5 from Andrew Macleod ---
Do you have a test case which shows what specifically is the issue? I suspect
its different from the included test case and it would be interesting to see
the real world situation. It may identify something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--- Comment #4 from Dmitry Vyukov ---
For the record, this bug is the result of my attempt to use std atomic
operations in ThreadSanitizer runtime. We do a bunch of relaxed loads and
stores during processing of every memory access in the target p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--- Comment #2 from Dmitry Vyukov ---
> Which is because to me it's not exactly clear as for what other operations an
atomic load/store is a barrier for.
That's trivial to answer -- memory_order_relaxed is barrier for nothing.
> But eventually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
