[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|ville.voutilainen at gmail dot com |redi at gcc dot gnu.org

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Barry Revzin from comment #8)
> Whereas the copy_b case could also use memmove.

I'd been working on the assumption that it can't, because for types that aren't
trivially default constructible we need a constructor to begin the lifetime.
But the rules for implicit-lifetime class types only require at least one
trivial constructor and a trivial destructor, so a trivial copy constructor is
enough. And memcpy/memmove implicitly create objects in the destination
storage.

I don't think that was really explicit before the implicit-lifetime rules in
C++20. The example in C++17 [basic.types] p3 implies that the destination
doesn't need to be an initialized object, but nothing said that normatively.
Quite the opposite: C++17 [basic.life] seems clear that initialisation must be
done for types with non-vacuous initialization (such as Barry's type B), and
nothing in C++17 said that memcpy/memmove do any initialization. C++20 is clear
though.

So:

- If the input and output type are the same size and both are trivially
  constructible, we can use memcpy. We should call memcpy directly from
  std::uninitialized_copy rather than via std::copy, because std::copy doesn't
  allow overlapping ranges, and has to use memmove instead.

- If the output type is trivially default constructible and is assignable from
  the input type, we can use std::copy (but it's unclear whether that gives any
  benefit if we can't turn it into memcpy/memmove).

- Otherwise, just use std::construct_at on each element.

I have a patch, but it's for stage 1 not GCC 12.