https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2023-01-31
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> I missed -std=c++20 part before. The rebind fixes the compiliation issue
> without -std=c++20 ....
Right, but the bug report is about c++20 mode, and the rebind isn't needed in
C++20 (because std::allocator<T>::rebind doesn't exist, so the default
implementation of rebinding does the right thing for alloc<T>).
(In reply to Andrew Pinski from comment #6)
> With clang and libc++ we get:
>
> /opt/compiler-explorer/clang-trunk-20230131/bin/../include/c++/v1/__memory/
> uninitialized_algorithms.h:597:3: error: static assertion failed due to
> requirement '__is_cpp17_move_insertable<b::alloc<a>, void>::value': The
> specified type does not meet the requirements of Cpp17MoveInsertable
> static_assert(__is_cpp17_move_insertable<_Alloc>::value,
> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Which I think is the best error message really. libstdc++v3 should add a
> similar static assert I think.
I think this is a libc++ bug in their __cpp17_move_insertable trait, which just
uses is_move_constructible here, which is false because of the private
destructor.
I agree there's a bug here, but I'm not sure where yet.
