https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
torvald at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |torvald at gcc dot gnu.org --- Comment #11 from torvald at gcc dot gnu.org --- (In reply to Alexander Monakov from comment #7) > I've submitted a patch [1] for the missing compiler barrier, but however > please note that the original ompi code and the example in comment #3 are > wrong: in a pattern like > > while (*foo) > __atomic_thread_fence(__ATOMIC_ACQUIRE); > > I think there are two issues; first, if *foo is a non-atomic, non-volatile > object, a concurrent modification from another thread would invoke undefined > behavior due to a data race; It would be a data race even if it would be volatile but still non-atomic. I can see how making atomic_thread_fence a compiler barrier for non-atomics might help existing buggy code, but it would be sufficient it prevents certain reordering of atomics. Some more background and examples: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html