How does the compiler know, whether it can internally do a memcpy-like optimization for trivially copyable objects? Or it (nearly) never does?

Which would be a huge missed optimization opportunity for objects, which are meant for being copied in a simple way (=trivially copiable objects) - without having to read, modify and write back the last few bytes, or - if possible on the platform - without writing single bytes below the word size.
 

-----Ursprüngliche Nachricht-----
Von: Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mi 29.11.2023 16:11
Betreff: Re: [std-proposals] void std::optional<T>::abandon(void) noexcept
An: std-proposals@lists.isocpp.org;
CC: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>;
On Wed, Nov 29, 2023 Lénárd Szolnoki via Std-Proposals wrote:
>
> The precondition for memcpy is trivially copyable *and* not potentially
> overlapping. The former doesn't imply the latter.
>
> https://godbolt.org/z/xhsqdoz3s


I've been playing around with this on GodBolt:

   https://godbolt.org/z/Ecd338Go8

The output of this program on Linux x86_64 GNU g++ 13.2.0 is:

   Address of b.a.i == 140727507144480
   Address of b.a.ch == 140727507144484
   Address of b.maybe_extra_byte == 140727507144485
   77
   0

So I am able to screw up the value of 'maybe_extra_byte' by memcpy'ing
over the A object that exists inside B. Is this what the committee
intended?

If this _is_ what the compiler intended, then should every C++
compiler issue a diagnostic whenever you pass the address of a
'no_unique_address' object to memcpy?
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals