Hi, On Mon, 13 Nov 2017, Richard Biener wrote:
> The chance here is, of course (find the PR, it exists...), that SRA then > decomposes the char[] copy bytewise... > > That said, memcpy folding is easy to fix. The question is of course > what the semantic of VIEW_CONVERTs is (SRA _does_ contain > bail-outs on those). Like if you have > > struct A { short s; int i; } x; > struct B { int i; short s; } y; > > void foo () > { > x = VIEW_CONVERT <struct A> (y); > } > > so can you access padding via view-converting its value? Ada uses > VIEW_CONVERT punning on structures a _lot_ (probably the reason for the > SRA bailout). I would say a VIEW_CONVERT shouldn't be allowed to inspect padding on the RHS (and expected to clobber padding on the LHS). That is, if you want to really really access padding on some struct type you can only use memcpy. (Or view-convert it to some char[N] array, perhaps there it makes sense to copy padding, i.e. regard that as a block copy). The above example shows why I'm of this opinion. Both structs have padding at different place, and it overlaps a member in the other struct. I don't see how to give that any sane meaning (beyond always handling it as block copy, and which point we can as well give up and get rid of VIEW_CONVERT_EXPR in favor of explicit memcpy). Ciao, Michael.