https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70191
Bug ID: 70191
Summary: libatomic library does not have lock-free
implementation for 16-bytes data object on Solaris
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alexey.lapshin at oracle dot com
Target Milestone: ---
__atomic_always_lock_free reports TRUE for 16-byte data object.
inlined implementation uses lock-free instruction for load 16-byte atomic
object.
At the same time __atomic_load_16 routine from libatomic library does not use
lock-free implementation. This looks incorrect.
-bash-4.1$ uname -a
SunOS 5.11 11.1 i86pc i386 i86pc
-bash-4.1$ cat atomic_load.c
#include <stdatomic.h>
#include <stdio.h>
typedef struct {
char a[16];
} test;
int main()
{
test y = {0};
_Atomic test x = ATOMIC_VAR_INIT(y);
printf("\n __atomic_always_lock_free(sizeof(x), &x) %d ",
__atomic_always_lock_free(sizeof(x), &x) );
y = atomic_load (&x);
return 0;
}
-bash-4.1$ gcc -m64 atomic_load.c -latomic -march=nehalem
-bash-4.1$ a.out
__atomic_always_lock_free(sizeof(x), &x) 1 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-bash-4.1$ gcc -m64 atomic_load.c -latomic -march=nehalem -S
-bash-4.1$ grep cmpx atomic_load.s
lock cmpxchg16b (%rsi) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-bash-4.1$
If I would compile example without -march=nehalem then a call to libatomic
__atomic_load_16 library function would be inserted. But that function does not
use "lock cmpxchg16b" it uses locked implementation.
-bash-4.1$ ldd a.out
libatomic.so.1 => /gcc/5.2.0/intel-S2/lib/amd64//libatomic.so.1
libc.so.1 => /lib/64/libc.so.1
libpthread.so.1 => /lib/64/libpthread.so.1
libm.so.2 => /lib/64/libm.so.2
So it looks like a bug that libatomic library have non lock-free implementation
on Solaris.
