https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #45 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> --- (In reply to mwahab from comment #44) > (In reply to James Greenhalgh from comment #43) > > (In reply to torvald from comment #37) > > > > > > I'm not worried about __sync_lock_release, I think the documentation is > > > > strong enough and unambiguous. > > > > > > Are you aware that the GCC's __sync disallow store-store reordering across > > > __sync_lock_release, whereas the psABI docs don't? > > > > No I was not, and even looking exactly for the text you were referring to, > > it took > > me three attempts to spot it. Yes, I understand now why you are concerned > > about > > the GCC wording. Perhaps this is just an artefact of a mistake transcribing > > the psABI? > > > > AArch64 is certainly not providing that guarantee just now. > > I wasn't able to find the text, could you copy it in a reply. > In the GCC manual, the only description of __sync_lock_release behaviour is > in the last paragraph. That descriptions seems consistent with the function > being a release barrier and with the current Aarch64 code generated for it. Yes, so this part is fine... void __sync_lock_release (type *ptr, ...) This built-in function releases the lock acquired by __sync_lock_test_and_set. Normally this means writing the constant 0 to *ptr. This built-in function is not a full barrier, but rather a release barrier. This means that all previous memory stores are globally visible, and all previous memory loads have been satisfied, And this final sentence is buggy by omission of a mention of memory writes: but following memory reads are not prevented from being speculated to before the barrier. Which can be read as forbidding store-store reordering across the barrier. As I say though, I think this is an artefact of transcribing the documentation, rather than an attempt to provide stronger ordering semantics in the GCC implementation.
