On Wed, Nov 8, 2017 at 3:22 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Wed, Nov 8, 2017 at 3:45 PM, Michael Matz <m...@suse.de> wrote:
>> Hi,
>>
>> On Wed, 8 Nov 2017, Richard Biener wrote:
>>
>>> Not sure how - the issue is the FIELD_DECLs overlap which rules out a
>>> RECORD_TYPE and leaves us with a UNION_TYPE.
>>
>> No, as the initial mail already mentioned, for the example in
>> question the overlapping fields can be put into a union which itself is
>> part of a struct:
>>
>> struct S {
>> union { T mem1[len]; T overlap1[len]; };
>> union { T mem2[len]; T overlap2[len]; };
>> };
>>
>> If you do real fancy equivalences with partial overlaps then you're right,
>> the type necessarily will look strange then. But for this example the
>> type could be improved (if that helps anything I don't know, though).
>
> Sure - for some cases the type representation can be improved, but
> generally we either have to go the BIT_FIELD_REF route or not assume
> that union members start at offset zero and thus not multiple ones can
> be live at the same time.
So I have two questions here.
A) Is this special kind union type only generated by fortran FE for
equivalence+common?
B) For the special union type that has non-zero offset fields. Is it
safe to assume field A is not the last flex array: if there is field B
that offset_B >= (offset_A + length_A)?
Thanks,
bin
>
> Richard.
>
>>
>> Ciao,
>> Michael.
