__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 not defined on aarch64

[Richard Earnshaw (lists)]

On 30/06/17 10:11, Alexander Monakov wrote:
> On Fri, 30 Jun 2017, Andrew Haley wrote:
>> Perhaps so.  However, it would make more sense and be more maintainable
>> if, rather than use a command-line option, a variable attribute was used
>> to tell the compiler what this program is supposed to mean.  IMO.
> 
> Correction: this can't be a variable attribute, because when you take a pointer
> to such object, the property remains relevant to the result of dereferencing
> that pointer.  Therefore, it would need to be a type attribute as Richard said.
> 
> I'd caution against adding attributes due to source code uglification and
> compiler compatibility concerns.
> 
> An option is also simple; adding the attribute would be repeating history with
> refusing native 128-bit CAS-based atomics due to r/o issue: creating extra work
> for compiler writers and frustration for users, only to handle an edge case they
> don't care about.
> 

NO.  AN OPTION WILL NOT WORK.

An option cannot fix up existing binary objects and change the ABI that
they expect.  You cannot force a recompile on all users so the ABI for
this type is NOW FIXED.

Mixing objects with potentially different ABIs in play is a recipe for
disaster.

As they say: Get over it.


R.

> Alexander
>