https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70490
torvald at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |torvald at gcc dot gnu.org
--- Comment #7 from torvald at gcc dot gnu.org ---
(In reply to Michael Poole from comment #0)
> When compiling for x86-64 with the -mcx16 flag, there is no diagnostic for
> code like this:
>
> #include <sys/mman.h>
> __int128 test(void)
> {
> const void *ptr = mmap(0, 4096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0);
> const __int128 *p_v = (const __int128 *)ptr;
> return __atomic_load_n(p_v, __ATOMIC_SEQ_CST);
> }
>
> The CMPXCHG16B instruction that is generated unconditionally attempts to
> write to the address, which causes a fault at runtime. When
> __atomic_load_n() uses that instruction, it seems prudent to reject a const
> pointer as the first argument.
I guess we haven't spelled that out in the docs, but the thought is that one
would use the __atomic builtins like one would use C11/C++11 atomics. In that
world, only "address-free" atomic types are guaranteed to work when mapped from
another process, for example, and only lock-free types are address-free. (That
doesn't quite cover all cases, such as when making process-private read-only,
but it gives at least some idea of what's the intent.)
Users should ensure that the particular type is lock-free (or that atomic ops
on that type are) to know that it's safe to use atomic loads on read-only
memory. The most recent GCC shouldn't declare the types to be lock-free just
because cmpxchg16b is available.
It might still use it under the covers, but the fact that it's not lock-free
indicates that the implementation is not just native atomic operations as
supported by the hardware, but something different.
I guess we need to spell this out in the docs.
