This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]