https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121946
Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |arthur.j.odwyer at gmail dot
com
--- Comment #10 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
FWIW, I totally support the proposed change of libstdc++'s
__is_bitwise_relocatable<T> from
struct __is_bitwise_relocatable : is_trivial<_Tp> {};
to
struct __is_bitwise_relocatable : is_trivially_copyable<_Tp> {};
I have been doing this (and actually going even further, to whitelist all types
that satisfy P1144 __is_trivially_relocatable(T)) in my own libstdc++ fork
since at least December 2023. See
https://github.com/Quuxplusone/gcc/commit/8489c3ed841826f490f4f970901ae64f04eeb51a
et prev.
Also, C++26 formally deprecates is_trivial<T>, which IMHO is a great excuse to
revisit, refurbish, and replace its use here with the more precisely targeted,
self-documenting, and performance-enhancing is_trivially_copyable<T>.
However, to give "equal time to the opposition," it must be noted that
libstdc++ has had this entire discussion at least once before. At last report,
libstdc++'s maintainers were under the impression that trivial copyability
gives permission to memcpy one object *over* another, but does not give
permission for memcpy to *create* abstract-machine objects in the first place.
(Whereas, for some reason, they think full triviality does — or maybe they
think trivial default-constructibility does — the two are not synonymous, and
I'm not sure there's any textual support for either position, although it makes
sense *if* you imagine that a trivial default constructor must have no
user-visible effect, and *if* you imagine the abstract machine can't tell the
difference between the no-visible-effect that happens when you call such a
constructor and the no-visible-effect that happens when you don't.)
See jwakely's 2020 comment at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106#c25
This theory, or something like it, might also be what derailed this 2024 effort
(also by jwakely) to whitelist std::pair<int,int> as bitwise relocatable:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
I notice that std::optional<int> also isn't marked bitwise relocatable, when it
could be (in fact it could be trivially copyable if not for ABI breakage).
