__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

[Toebs Douglass]

On 29/06/17 12:14, Andrew Haley wrote:
> On 29/06/17 10:40, Alexander Monakov wrote:
>> On Thu, 29 Jun 2017, Andrew Haley wrote:
>>> I think I now properly understand Richard Earnshaw's point: that we
>>> *do* support a full set of atomic primitives for 16-byte types via
>>> libatomic, but for them to work as a sequentially-consistent set we
>>> must use the same locking scheme for all of them.  It's ugly, and
>>> horrible for anyone who simply wants a double-word CAS, but it is what
>>> it is.  We can't use LDXP because it isn't atomic on its own, and the
>>> ARM manual is quite explicit about this.  Anyone who wants to use
>>> a real compare-and-swap-16 is on their own.
>>
>> Note that there's no 'atomic read' primitive among __sync builtins, so
>> IMO it gives a way out: expose native doubleword cas via __sync_compare_and_swap,
>> use a locking scheme for its __atomic counterpart.
> 
> So it does.  Good idea.  Although documenting the incompatibility between
> __atomic and __sync might be rather problematic.  :-)

I'd very much this was not done.  I may be wrong, but I think it is easy
and natural for people to grasp the idea that __atomic supersedes
__sync, and so they simply forget about __sync.  Adding new
functionality to __sync, so it continues to live on and indeed offers
functionality unavailable in __atomic, is confusing.  I'd look instead
to a new intrinsic in __atomic (which makes documentation clearer, as
it's all in one place).

Also, __sync is a pain - the API is much less pleasant than __atomic,
with regard to memory models and built-in compiler barriers.  Using
__atomic is much easier, and as soon as you use anything from __sync,
you then have other stuff to handle, which is otherwise handled
inherently by __atomic.