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 #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.


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