https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87604
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |https://gcc.gnu.org/piperma
| |il/gcc-patches/2024-Decembe
| |r/671344.html
Keywords| |patch
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I haz patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671344.html
That only changes __relocate_a, but the checks for whether the we can avoid
using the allocator should be generalized to use elsewhere in
bits/stl_uninitialized.h
As I wrote in that mail:
N.B. this doesn't benefit pmr::polymorphic_allocator because that has a
custom construct member, so that it can do uses-allocator construction.
We could potentially make it work, because we know that if the type
doesn't support uses-allocator construction then polymorphic_allocator
will construct objects the same way as std::allocator would. We would
need to check whether std::uses_allocator is true and the type has an
allcoator-extended move constructor (in either the leading or trailing
allocator form). Making that work is left for another day.
