This is a weird one as described in the PR. GCC doesn't complain about
this bug, but seems to have a bogus error elsewhere. I'll add a testcase
once I've understood/fixed the GCC error.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/110542
* include/bits/stl_uninitialized.h (__uninitialized_default_n):
Do not use std::fill_n during constant evaluation.
---
libstdc++-v3/include/bits/stl_uninitialized.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h
b/libstdc++-v3/include/bits/stl_uninitialized.h
index 6752c6b5746..be7b4afdd05 100644
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -695,6 +695,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
inline _ForwardIterator
__uninitialized_default_n(_ForwardIterator __first, _Size __n)
{
+#ifdef __cpp_lib_is_constant_evaluated
+ if (std::is_constant_evaluated())
+ return __uninitialized_default_n_1<false>::
+ __uninit_default_n(__first, __n);
+#endif
+
typedef typename iterator_traits<_ForwardIterator>::value_type
_ValueType;
// See uninitialized_fill_n for the conditions for using std::fill_n.
--
2.41.0
