On 26/02/18 04:00, Ruslan Nikolaev via gcc wrote:
1. Not consistent with clang/llvm which completely supports double-width
atomics for arm32, arm64, x86 and x86-64 making it possible to write portable
code (w/o specific extensions or assembly code) across all these architectures
(which is finally possible with C11!)
this should be reported as a bug against clang.
there is no abi guarantee that double-width atomics
will be able to synchronize with code in other modules,
you have to introduce a new abi to do this whatever
that takes (new elf flag, new dynamic linker name,..).
4. atomic_load can be implemented using read-modify-write as it is the only
option for x86-64 and arm64 (see below).
no, it can't be.
[..] The actual nature of read-only memory and how it can be used are
outside the scope of the standard, so there is nothing to prevent atomic_load
from being implemented as a read-modify-write operation.
rmw load is only valid if the implementation can
guarantee that atomic objects are never read-only.
current implementations on linux (including clang)
don't do that, so an rmw load can observably break
conforming c code: a static global const object is
placed in .rodata section and thus rmw on it is a
crash at runtime contrary to c standard requirements.
on an aarch64 machine clang miscompiles this code:
$ cat a.c
#include <stdatomic.h>
static const _Atomic struct S {long i,j;} x;
int f(const _Atomic struct S *p)
{
struct S y = *p;
return y.i;
}
int main()
{
return f(&x);
}
$ gcc a.c -latomic
$ ./a.out
$ clang a.c -latomic
$ ./a.out
Segmentation fault (core dumped)
