[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

["matthew.wahab at arm dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

--- Comment #4 from Matthew Wahab <matthew.wahab at arm dot com> ---
There is a difference between __syncs and __atomics, assuming the the __atomics
are meant to match the C11/C++11 memory model. With C11 atomics, a barrier for
an operation on an object only affects memory references related to that
object. So __atomic_add_fetch(&foo, 1, __ATOMIC_SEQ_CST) is only a full barrier
for references that can affect the value of foo, other references can be moved
around it. The documentation for the __sync builtins is clear that the
__sync_fetch_and_add is a barrier that affects all memory references.

There are C11 fences which make __ATOMIC_SEQ_CST act as a barrier for all
memory references but these are distinct from the operations on a memory
location.

Descriptions of C11 atomics are a little opaque, the relevant sections in the
C11 standard seem to be 5.1.2.4-9 Note 4 ("There is a separate order for each
atomic object") and 7.17.3-7 (limiting memory_order_seq_cst to affected
locations). Torvald Riegels email, linked above, explains it better. It's from
a similar discussion about the Aarch64 implementation of MEMMODEL_SEQ_CST for
the __atomic builtins.