[Bug libstdc++/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 27 Sep 2016, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77686
> 
> --- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #14)
> > Just to explain a little bit.  Consider
> > 
> > void foo (void)
> > {
> >   union { float f; char c[4]; } u, v;
> >   *(int *)&u = 0;
> >   v = u;
> >   return *(int *)&v;
> > }
> > 
> > then C11 6.5/6,7 make it clear that it is not valid to use 'u' (of union
> > type)
> > to access the object which now has effective type 'int' (in fact that store
> > alone, given strict reading of C11 6.5/6 is invalid as u has a declared
> > type).
> > The union does not have 'int' amongst its members.  Putting 'char' or an
> > array of 'char' into the union does not make the access fall under 6.5/7
> > as 'a character type' only follows 'an aggregate or union type that includes
> > one
> > of the _AFOREMENTIONED_ types...' (emphasis mine).
> 
> But would *(int*)u.c be OK, because that is a character type? Given that C++
> does define what the assignment means for the union, we just need to make sure
> we do *(int*)u.c not *(int*)&u or is that still not enough?

No, *(int *)u.c is not OK, because that's still 'int', not a character 
type (because of the cast).

> If not, what does the last bullet of 6.5/7 allow?

It allows

  *(char *)&u

basically it allows a memcpy implementation to exist.