This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
- From: "mikulas at artax dot karlin.mff.cuni.cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 06 Jul 2015 15:00:05 +0000
- Subject: [Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier
- Auto-submitted: auto-generated
- References: <bug-59767-4 at http dot gcc dot gnu dot org/bugzilla/>
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.