This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
- From: "jgreenhalgh at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 29 Apr 2015 12:20:28 +0000
- Subject: [Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
- Auto-submitted: auto-generated
- References: <bug-65697-4 at http dot gcc dot gnu dot org/bugzilla/>
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.