[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier

["mikulas at artax dot karlin.mff.cuni.cz" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
The problem here is that we don't really know what does the standard specify.

People often suggest the Batty's paper Mathematizing C++ Concurrency (
http://www.cl.cam.ac.uk/~pes20/cpp/popl085ap-sewell.pdf ) as the explanation,
but the paper really describes a different memory model than the C++ standard
(citing section 4: "Unfortunately N3092 allows the following nonsequentially
consistent execution of the SB example with SC atomics (initialisation writes,
such as (a) and (b), are non-atomic so that they need not be compiled with
memory fences): - We devised a stronger restriction on the values that may be
read by SC atomics, stated in Â2.7, that does provide sequential consistency
here." - so it doesn't describe the standard, but something stronger that
authors have "devised")

You can look at this example https://gcc.gnu.org/ml/gcc/2014-02/msg00053.html .
The assert can fail - so it implies that __ATOMIC_SEQ_CST is not a full
barrier, it is somehow weaker. But how much weaker is it? Who knows?

I look at https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html and I would
really like to know "why is it so?" "Where does the standard specify this
mapping?" I couldn't really find an answer for that.