https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #16 from Andrew Haley <aph at gcc dot gnu.org> --- (In reply to mwahab from comment #14) > (In reply to Andrew Haley from comment #13) > > 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. Right. > I'll have to look at the compare-exchange code, it does looks like it goes > wrong. Well... goes wrong how? If it's intended to be a C++11 sequentially-consistent CAS, it's just fine.
