https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #11 from Matthew Wahab ---
(In reply to Andrew Macleod from comment #10)
> (In reply to Matthew Wahab from comment #7)
>
> > Ok, my point was just that an __sync operation has a stronger barrier that
> > an __atomic operation.
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #9 from Matthew Wahab ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Matthew Wahab from comment #7)
> > I agree that this wouldn't affect valid C11 code (because of data-races) but
> > my understanding is that __sync
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #7 from Matthew Wahab ---
(In reply to torvald from comment #5)
> (In reply to Matthew Wahab from comment #0)
> > The __sync builtins are implemented by expanding them to the equivalent
> > __atomic builtins, using MEMMODEL_SEQ_CST fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #4 from Matthew Wahab ---
There is a difference between __syncs and __atomics, assuming the the __atomics
are meant to match the C11/C++11 memory model. With C11 atomics, a barrier for
an operation on an object only affects memory ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #1 from Matthew Wahab ---
I'm working on this but it isn't obvious how to fix it. The strong barriers
aren't needed for the __atomics and will have an effect on performance so
simply strengthening the MEMMODEL_SEQ_CST implementation i
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matthew.wahab at arm dot com
The __sync builtins are implemented by expanding them to the equivalent
__atomic builtins, using MEMMODEL_SEQ_CST for those that are full barriers.
This is too
Assignee: unassigned at gcc dot gnu.org
Reporter: matthew.wahab at arm dot com
Created attachment 34964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34964&action=edit
Testcase showing change in behaviour.
The ARM backend no longer supports -mno-lra so only the LRA is av
