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.
