https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #14 from mwahab at gcc dot gnu.org --- (In reply to Andrew Haley from comment #13) > There's surely a documentation problem here. > > GCC defines this: > > `__ATOMIC_SEQ_CST' > Full barrier in both directions and synchronizes with acquire > loads and release stores in all threads. The documentation is a little misleading. Barriers in __atomic operations are slightly weaker then barriers in __atomic fences; the differences are rather subtle though. For the __sync implementation an fence would be ok but an operation is too weak. > But LDAXR/STLXR doesn't do that, and there's no write barrier at all when > the compare fails. If the intention really is to map onto c++11, this > specification is wrong. The LDAXR/STLXR sequences rely on the C11/C++11 prohibition of data races. That the __atomic builtins assume this restriction is implied by the references to C11/C++11 in the documentation but should probably be made clearer. I'll try to write a patch, if nobody else gets there first. I'll have to look at the compare-exchange code, it does looks like it goes wrong.
