https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #71 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #68)
> (In reply to Jonathan Wakely from comment #65)
> > It accesses b, but it doesn't access the object stored in b's char[N] member
> > via placement new.
>
> Okay, let's go with this. So the copying of the union is then defined
> (as a memcpy equivalent). Then there's still the question if the following
> sequences are valid:
>
> // assume T1 and T2 are some types and new is trivial placement new
> union U {T1 a; char b[sizeof T2];} x,y;
> new (x.b) T2(); // 1
> y = x; // 2
> T2 t;
> memcpy(&t, y.b, sizeof T2); // 3
> t; // 4
> y.a; // 5
>
> We have said that (2) is valid, obviously (3) in isolation is valid as well,
N.B. (3) is not valid if T2 isn't trivially copyable. But for the cases we care
about, it is (the code takes a completely different path otherwise).
> but it influences the validity of (4). (5) is invalid as it's not the
> active member of the union y (which is instead b).
>
> (4) is valid if y.b contained a T2, which is only the case if (2) transferred
> the dynamic type from x.b _and_ (1) was valid to start with and dynamically
> typed x.b to be of type T2.
>
> So, it all boils down to if (1) is valid and types x.b to T2, even though it
> has a different declared type.
I don't think it changes the type of x.b, but it does begin the lifetime of an
object of type T2 at that location.
As I see it, the question is whether copying the object representation of that
object to another location means we have another object at the second location.
We all seem to agree that copying the object representation using memcpy *does*
do that. We don't agree whether copying the object representation via an
implicit union copy does that.
I don't see a distinction between copying the object representation via memcpy
or the union copy.
