https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #11 from Matthew Wahab <matthew.wahab at arm dot com> --- (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. > > > > 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. The gcc manual page for the __atomics does suggest that ATOMIC_SEQ_CST is a full barrier so should be equivalent to the __sync full barrier. There is a difference though and that does mean that the semantics of __sync builtins was changed by the merge with __atomics. > 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. Aarch64 support first went into GCC 4.8 and the __atomic/__sync merge went into GCC 4.7. I took a look the __sync implementation in GCC-4.6: the builtins would expand to the sync_* instructions if a backend provided them and fall back to a compare-swap loop otherwise. For backends that provided sync_* instructions, it looks like the operations were treated as a full barrier (applying to all memory references). This is still the case for the __atomics on some targets; e.g. i386 uses lock <inst> which apparently acts as a full barrier. The compare-swap loop didn't emit any kind of barrier. > The intention was also to deprecate __sync so I wouldn't put too much > thought into it. New code should certainly be pointed at the __atomics but there's likely to be a lot existing code using __syncs. It should be possible to move it to a new architecture without having to do potentially painful rewrites.
