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

mwahab at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Apr 15 11:11:00 GMT 2015


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.



More information about the Gcc-bugs mailing list