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: "amacleod at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 09 Apr 2015 11:51:44 +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 #10 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Matthew Wahab from comment #7)
> (In reply to torvald from comment #5)
> > (In reply to Matthew Wahab from comment #0)
> >
> > I don't think that's a precise characterization. The difference discussed
> > in that thread is that seq-cst fences have a stronger effect than seq-cst
> > stores. This is not really a question of MEMMODEL_SEQ_CST but what you
> > apply it to.
>
> Ok, my point was just that an __sync operation has a stronger barrier that
> an __atomic operation.
>
I think that is just an interpretation problem or flaw in my documentation. It
was never meant to indicate any difference between __sync and MEMMODEL_SEQ_CST.
Have you tried it on a gcc before __atomic and __sync were merged? probably GCC
4.7 and earlier. The code should be identical. Of course, changes to the
machine description patterns could result in differences I suppose... but the
intent is that SEQ_CST and __sync are the same... hence the code base was
merged.
The intention was also to deprecate __sync so I wouldn't put too much thought
into it.