This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about generated type for common block in fortran
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "Bin.Cheng" <amker dot cheng at gmail dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Date: Wed, 8 Nov 2017 16:22:52 +0100
- Subject: Re: Question about generated type for common block in fortran
- Authentication-results: sourceware.org; auth=none
- References: <CAHFci2-Ou3jwFk0v=_hrUpeSHCpVM-Lb9JnTNDckmieAzTkzvQ@mail.gmail.com> <F09FC826-F13A-4E39-A24F-3D9E37628A92@gmail.com> <alpine.LSU.2.21.1711071650200.25295@wotan.suse.de> <CAFiYyc1qy7nfZFoT9g90ecx6SBU5P9s_9=Rtte6x+F_kfNKrJw@mail.gmail.com> <alpine.LSU.2.21.1711081541170.25295@wotan.suse.de>
On Wed, Nov 8, 2017 at 3:45 PM, Michael Matz <matz@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.
Richard.
>
> Ciao,
> Michael.