GCC in-line assembly and the removal of -mcx16

Andrew Haley aph@redhat.com
Tue May 30 13:57:00 GMT 2017


On 30/05/17 11:28, Jonathan Wakely wrote:
> On 28 May 2017 at 12:15, Toebs Douglass wrote:
>> I would like to write a little about the new libatomic mechanism for
>> What I see however is that there is a way for me to avoid these costs
>> and return to the simple situation.  My code has an abstraction layer,
>> and I can implement inline assembly for double-word CAS on 64-bit
>> platforms and use that instead of __atomic and __sync.
> 
> On x86_64 can't you just use __sync_val_compare_and_swap with -mcx16?
> 
> Since GCC 4.6 this always emits cmpxchg16b when compiled with -mcx16:
> 
> int main()
> {
>   __int128 i = 0;
>   __sync_val_compare_and_swap(&i, 0, 1);
> }
> 
> That still works with GCC 7.

I just built GCC from trunk, and this gives me:

mustang-b0:~ $ /scratch/gcc/trunk/install/bin/gcc zzz.c
/tmp/ccmc3Y73.o: In function `main':
zzz.c:(.text+0x20): undefined reference to `__sync_val_compare_and_swap_16'
collect2: error: ld returned 1 exit status

I can't figure out where __sync_val_compare_and_swap_16 should be
defined.  It's not in libatomic or libc or libgcc.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the Gcc-help mailing list