On Wed, Feb 04, 2026 at 12:14:18PM +0100, Tomasz Kaminski wrote: > On Tue, Feb 3, 2026 at 8:57 PM Marek Polacek <[email protected]> wrote: > > > On Tue, Feb 03, 2026 at 10:46:14AM +0000, Jonathan Wakely wrote: > > > On Mon, 2 Feb 2026 at 19:37, Marek Polacek <[email protected]> wrote: > > > > > > > > Bootstrapped/regtested on ppc64le-pc-linux-gnu, ok for trunk? > > > > > > > > -- >8 -- > > > > [allocator.members] says that allocator::{,de}allocate should be > > > > constexpr but currently we don't mark them as such. I had to > > > > > > We do mark std::allocator::allocate and deallocate, the ones you're > > > changing below are std::__new_allocator::allocate and > > > std::__new_allocator::deallocate, which should never be used during > > > constant eval: > > > > Aha. > > > > > include/bits/allocator.h has: > > > > > > #if __cplusplus > 201703L > > > [[nodiscard,__gnu__::__always_inline__]] > > > constexpr _Tp* > > > allocate(size_t __n) > > > { > > > if (std::__is_constant_evaluated()) > > > { > > > if (__builtin_mul_overflow(__n, sizeof(_Tp), &__n)) > > > std::__throw_bad_array_new_length(); > > > return static_cast<_Tp*>(::operator new(__n)); > > > } > > > > > > return __allocator_base<_Tp>::allocate(__n, 0); > > > } > > > > > > [[__gnu__::__always_inline__]] > > > constexpr void > > > deallocate(_Tp* __p, size_t __n) > > > { > > > if (std::__is_constant_evaluated()) > > > { > > > ::operator delete(__p); > > > return; > > > } > > > __allocator_base<_Tp>::deallocate(__p, __n); > > > } > > > #endif // C++20 > > > > > > > > > and __allocator_base is __new_allocator (for the default configure > > > flags anyway). > > > > > > So I'm surprised that the __new_allocator members need fixing. Why > > > does the reflection code ever end up looking at the __new_allocator > > > members? > > > > bases_of uses std::vector<info> so we instantiate > > > > constexpr _Tp* std::allocator<<...>::allocate(std::size_t) [with _Tp = > > std::meta::info; std::size_t = long unsigned int] > > > > which due to the "return __allocator_base<_Tp>::allocate(__n, 0)" > > instantiates > > > > _Tp* std::__new_allocator<_Tp>::allocate(size_type, const void*) [with > > _Tp = std::meta::info; size_type = long unsigned int] > > > > which has > > > > return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n * sizeof(_Tp))); > > > > in its body. _Tp is std::meta::info so we think this is a consteval-only > > expression, but std::__new_allocator::allocate isn't an "instantiation of > > a templated entity defined with the constexpr specifier" so we can't > > promote it to consteval so we error. With the added constexpr we can > > promote it to consteval and we don't error. > > > > Sorry that the original mail didn't explain this. > > This does not impact the above change. > I wonder if else branch of if consteal should be discarded in immediate > functions, so if I have: > template<typename T> > constexpr void foo() > { > if consteval { > return const_impl<T>(); > } else { > return runtime_impl<T>(); > } > } > Then runtime_impl<T> does not need to be consteval, and thus have code > available inline.
FWIW, I did try using if consteval in std::allocator::allocate but it didn't help :(. Marek
