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
