[Bug c/70191] New: libatomic library does not have lock-free implementation for 16-bytes data object on Solaris

["alexey.lapshin at oracle dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.