[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenther at suse dot de]

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.