C++20's P0528R3/P1123R0 not implemented (atomic ignoring padding bits)

[comex]

C++20 includes P0528R3 and P1123R0, which together require std::atomic<T>::compare_exchange_strong and std::atomic_ref<T>::compare_exchange_strong to ignore any padding bits that exist in T.

However, this is not implemented in Clang or libc++ as of b41e75c. Also, neither paper is mentioned on the cxx_status page.

As a result of the missing implementation, the following prints 0 when it should print 1:

#include <atomic>
#include <stdio.h>
int main() {
    struct HasPadding { char a; short b; };
    HasPadding expected{};
    std::atomic<HasPadding> atomic(expected);
    ((char *)&expected)[1] = 0x42; // update padding byte
    printf("%d\n", atomic.compare_exchange_strong(
        expected, expected));
}

See also:

• this comment which includes a comparison of different compilers;
• Implement __builtin_zero_non_value_bits which was recently added to MSVC for P0528R3 and P1123R0 #46030 for an intrinsic that MSVC's C++ standard library implementation uses as part of its implementation;
• Implement __builtin_clear_padding (used by libstdc++ for P0528R3/P1123R0) #64830 for an intrinsic that libstdc++ uses as part of its implementation

[RalfJung]

Relatedly, it would be good to get clarification on the behavior of LLVM's cmpxchg when the value being compared is partially undef / uninitialized / poison (which is what happens with the above program). Naively, the answer would be "it's UB" (that's usually what happens when you memcp memory that contains undef / uninitialized / poison), but that would make it impossible to perform cmpxchg on data with padding which would be unfortunate.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

[huixie90]

On the libc++ side, we need clang equivalent of gcc __builtin_clear_padding to make it implementable. Also notice that for long double in the x87_fp80 format, gcc __builtin_clear_padding also clears the last 58 bits as only first 80bits of the long double is the value representation

[gonzalobg]

Is there an issue tracking __builtin_clear_padding ?

[pkasting]

Is there an issue tracking __builtin_clear_padding ?

Yes, #64830.

[ldionne]

Closing as a duplicate of:

• libc++ P0528R3: The Curious Case of Padding Bits, Featuring Atomic Compare-and-Exchange #99984 and P1123R0: Editorial Guidance for merging P0019r8 and P0528r3 #99991
• Clang's Implement __builtin_clear_padding (used by libstdc++ for P0528R3/P1123R0) #64830