https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754
--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-15 branch has been updated by Jonathan Wakely <r...@gcc.gnu.org>: https://gcc.gnu.org/g:fcbedcae9b6f6df537ceb01f6f3378a7f5a99bb2 commit r15-9953-gfcbedcae9b6f6df537ceb01f6f3378a7f5a99bb2 Author: Jonathan Wakely <jwak...@redhat.com> Date: Tue Jul 8 10:48:21 2025 +0100 libstdc++: Fix __uninitialized_default for constexpr case [PR119754] We should not use the std::fill optimization for trivial types during constant evaluation, because we need to begin the lifetime of all objects, even trivially default constructible ones. This fixes a bug that Clang diagnosed: include/c++/16.0.0/bits/stl_algobase.h:925:11: note: assignment to object outside its lifetime is not allowed in a constant expression 925 | *__first = __val; | ~~~~~~~~~^~~~~~~ I initially just added the #ifdef __cpp_lib_is_constant_evaluated check, but that gave warnings with GCC because the function isn't constexpr until C++26. So then I tried checking __glibcxx_raw_memory_algorithms for the value indicating constexpr uninitialized_value_construct, but that macro depends on __cpp_constexpr >= 202406 and Clang 19 doesn't support constexpr placement new, so doesn't define it. So I decided to just change __uninitialized_default to use _GLIBCXX20_CONSTEXPR which is consistent with __uninitialized_default_n (which needs to be constexpr because it's used by std::vector). We don't currently need to use __uninitialized_default in constexpr contexts for C++20 code, but we might find uses for it, so now it would be possible. libstdc++-v3/ChangeLog: PR libstdc++/119754 * include/bits/stl_uninitialized.h (__uninitialized_default): Do not use optimized implementation for constexpr case. Use _GLIBCXX20_CONSTEXPR instead of _GLIBCXX26_CONSTEXPR. (cherry picked from commit 82d2d12da93b5afbc3479e64d0aa0dcec5b42d8d)
