[Bug target/70490] __atomic_load_n(const __int128 *, ...) generates CMPXCHG16B with no warning

torvald at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Feb 27 10:57:00 GMT 2018


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.


More information about the Gcc-bugs mailing list