On November 13, 2017 3:20:16 PM GMT+01:00, Michael Matz <m...@suse.de> wrote:
>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).
Eric should know constraints important for Ada.
Richard.
>
>Ciao,
>Michael.
