https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123875
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-15 branch has been updated by Tomasz Kaminski <[email protected]>: https://gcc.gnu.org/g:0ccfda02076f0265ad6a8267e1f2030b7eaae0c7 commit r15-10863-g0ccfda02076f0265ad6a8267e1f2030b7eaae0c7 Author: Tomasz KamiÅski <[email protected]> Date: Thu Jan 29 18:14:47 2026 +0100 libstdc++: Allow constant initialization of std::atomic of types with padding [PR123875] Currently for the types T that contains padding bits, std::atomic<T>(T) constructor was not usable at compile-time in C++14 or later modes. This regression caused by use of __builtin_clear_padding introduced in r13-2548-g157236dbd62164. This leads to two regressions when switching from C++11 to C++14 standard (or switching from GCC-12 to later version for C++14 standard), where for type X that contains padding * constexpr std::atomic<X> cx(X(...)) becomes ill-formed, * std::atomic<X> gx(X(...)) with static storage duration, switch from static to dynamic initialization. The latter breakage is silent and may introduced very hard to localize order of initialization issues. This patch mitigates above issue by not invoking the __builtin_clear_padding, during constant initialization (std::__is_constant_evaluated() is false). This is considered to be safe, as: * for objects with static storage duration, padding bits are already cleared by zero-initialization * for constexpr objects with non-static storage duration, there is no API that would allow user to observe padding bits on const atomic objects To elaborate on the second point, values of padding bits in atomic can be observed by: * The compare_exchange_weak/compare_exchange_strong operations are mutating, so cannot be invoked on const objects. * As atomic<X> is not required to store actual object of type X, observing its object representation does (via bitcast, memcpy), does not provide values of object representation of X. Furthermore, the operations are defined only for trivially_copyable types, and atomic specializations meets above requirement only due to bug in libstdc++ (see PR67572). Note that above will no longer hold, and the solution will need to be revisited during implementation of C++26 paper P3309R3: constexpr atomic and atomic_ref (it will be possible to call compare_exchange during constant evaluation). PR libstdc++/123875 libstdc++-v3/ChangeLog: * include/bits/atomic_base.h (__atomic_impl::__clear_padding): Use if constexpr unconditionally. (__atomic_float<_Fp>::__atomic_float(_Fp)): Skip __clear_padding call for constant evaluation. * include/std/atomic (atomic<_Tp>::atomic(_Tp)): Likewise. * testsuite/29_atomics/atomic/cons/zero_padding.cc: New test. * testsuite/29_atomics/atomic_float/zero_padding.cc: New test. Reviewed-by: Patrick Palka <[email protected]> Reviewed-by: Jonathan Wakely <[email protected]> Signed-off-by: Tomasz KamiÅski <[email protected]> (cherry picked from commits 6b550d69fe7cb62ea6e240ce7a4ba29ce33aa1b1 682c95b808724e6f876ea709b873ac6771704d7b 060d7c2a9c1fe16d23d98a74287fdb7c73ddb784 f3ba5ad088cebe117f857329a35b95d18d97a808)
