https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--- Comment #2 from Dmitry Vyukov <dvyukov at google dot com> --- > 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 that's by design to make locking primitives work (where we may not move any loads/stores into/out of the protected region). That's a very bad design for a production compiler. Locking primitives will necessary include memory_order_acquire/release atomic, and they will prevent unwanted code movement. Relaxed atomic must not prevent any code movement and also don't clobber anything. Similarly, memory_order_release should generally not prevent hoisting of loads above it. For the record, this is just fixed in clang compiler (did not test yet, though): http://llvm.org/bugs/show_bug.cgi?id=17281
