https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #37 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 24 Mar 2017, jason at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 > > --- Comment #36 from Jason Merrill <jason at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #34) > > C++14 12.8/16 says > > > > "The implicitly-defined copy/move constructor for a union X copies the > > object representation (3.9) of X." > > > > 3.9/4 says > > > > "The object representation of an object of type T is the sequence of N > > unsigned char objects... For trivially copyable types, the value > > representation is a set of bits in the object representation that determines > > a value,..." > > > > this suggests that the copying should work but the C++ FE may not simply > > elide the copy construction by emitting > > > > c = *p; > > > > because that does _not_ implement memcpy semantics for the union member. > > Nothing in the standard makes memcpy magic; 3.9/3 says, > > For any trivially copyable type T, if two pointers to T point to distinct T > objects obj1 and obj2, where neither obj1 nor obj2 is a base-class subobject, > if the underlying bytes (4.4) making up obj1 are copied into obj2, obj2 shall > subsequently hold the same value as obj1. > > It just talks about copying the underlying bytes, not necessarily using memcpy > to do so. And a copy of a B is a memberwise copy, which implies copying the U > member, which as you quote means copying the object representation, which is > the underlying bytes. Yes. But then the act of copying, the c = *p; stmt needs to still follow 3.10/10, *p is not a valid glvalue to access the object live in p->u.b which is of type A.
