Re: Question about generated type for common block in fortran
On Tue, Nov 7, 2017 at 4:55 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 26 Oct 2017, Richard Biener wrote:
>
>> >Hi,
>> >I am looking into DSE transformation of some fortran codes. Given
>> >below fortran declarations:
>> >
>> > real*8 a(len) , b(len) , c(len) , d(len)
>> > common /area/ a, b, c, d
>> > real*8 src1(len), temp1(len), temp2(len), src2(len)
>> > equivalence(src1, a), (src2, b), (temp1, c), (temp2, d)
>> >
>> >with my limited understanding of fortran, the layout should be like:
>> >struct area
>> >{
>> > union {double src1[len]; double a[len]};
>> > union {double temp1[len]; double b[len]};
>> > union {double temp2[len]; double c[len]};
>> > union {double src2[len]; double d[len]};
>> >};
>>
>> I guess equivalence with mismatching size and overlaps makes this a
>> difficult representation. Not that such equivalence would be valid...
>>
>> >When debugging in tree-ssa-dse.c, if I have memory reference like
>> >area.src1[idx], the type for area dumped is like:
>> >(gdb) call debug_generic_expr(ref1->exp.operands[0])
>> >area
>> >(gdb) call debug_generic_expr(ref1->exp.operands[0]->typed.type)
>> >union
>> >{
>> > real(kind=8) src1[100];
>> > real(kind=8) a[100];
>> > real(kind=8) src2[100];
>> > real(kind=8) b[100];
>> > real(kind=8) temp1[100];
>> > real(kind=8) c[100];
>> > real(kind=8) temp2[100];
>> > real(kind=8) d[100];
>> >}
>> >I do noticed src1/src2 fields do have different offset, although they
>> >are put into a union type here.
>>
>> It's definitely stretching what I would consider a valid union type.
>> Maybe Ada does have similar layouts?
>
> Maybe it's rather an implementation artifact of trying to capture the
> effects of the unnamed members (of union type) that are in the struct. In
> the end it doesn't matter much for code generation: the field offsets
> matter, not if the surrounding type is a union or struct. It's confusing,
> though :) (and inhibits optimization that expect only "sane" types).
>
>> >I suppose such type are generated by fortran front-end? Is it just
>> >because it's easy to do so? And any background comment/document about
>> >this?
>> >Unfortunately middle end misses lots of dead store, redundant load
>> >because of difficulty in alias check of such type information. I
>> >guess fully support alias check of this issue would be non-trivial, so
>> >any suggestions will be highly appreciated too.
>
> You can probably change the fortran frontend to create saner types for
> this.
Not sure how - the issue is the FIELD_DECLs overlap which rules out
a RECORD_TYPE and leaves us with a UNION_TYPE. The only other
possibility is not create an aggegate for the equivalence at all but
always access the underlying object via BIT_FIELD_REFs (hopefully
the offsets of the fields are always compile-time known constants?).
Richard.
>
> Ciao,
> Michael.
Re: GCC Compilers info for the OpenMP Compilers page
Jakub, Ed, and/or GCC support, Appreciate if we could get an update for GCC. SC17 is just around the corner. Below is what we have for now. Open Source GCC Free and open source – Linux, Solaris, AIX, MacOSX, Windows, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, HPUX, RTEMS From GCC 4.2.0, OpenMP 2.5 is fully supported. From GCC 4.4.0, OpenMP 3.0 is fully supported. From GCC 4.7.0, OpenMP 3.1 is fully supported. In GCC 4.9.0, OpenMP 4.0 is supported for C and C++, but not Fortran. From GCC 4.9.1, OpenMP 4.0 is fully supported. From GCC 6.1, OpenMP 4.5 is fully supported for C and C++. Compile with -fopenmp to enable OpenMP. Online documentation: https://gcc.gnu.org/onlinedocs/libgomp/ OpenMP support history: https://gcc.gnu.org/projects/gomp/ Thanks! Helen On Thu, Nov 2, 2017 at 4:18 PM, Yun He wrote: > Hi Jakub, Ed, > > You helped in the previous year to provide the GCC compilers info > published at: > http://www.openmp.org/resources/openmp-compilers/ > > Could you please do so again now? Our goal is to have up-to-date info for > SC17. > > Please either edit the GDoc below directly (you may need Gmail to access), > or send me the entry via email, and I will add to it. > https://docs.google.com/document/d/1y-DVSSp4UB-rJ0oQdMNLThCoqRoxG- > XMY0DlTu6o7zk/edit?ts=59f36ac2 > > Thanks! > Helen >
Re: GCC Compilers info for the OpenMP Compilers page
On Wed, Nov 08, 2017 at 04:28:18AM -0800, Yun He wrote: > Jakub, Ed, and/or GCC support, > > Appreciate if we could get an update for GCC. SC17 is just around the > corner. > > Below is what we have for now. > > Open Source GCC Free and open source – Linux, Solaris, AIX, MacOSX, > Windows, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, HPUX, RTEMS > >From GCC 4.2.0, OpenMP 2.5 is fully supported. > >From GCC 4.4.0, OpenMP 3.0 is fully supported. > >From GCC 4.7.0, OpenMP 3.1 is fully supported. > In GCC 4.9.0, OpenMP 4.0 is supported for C and C++, but not Fortran. > >From GCC 4.9.1, OpenMP 4.0 is fully supported. > >From GCC 6.1, OpenMP 4.5 is fully supported for C and C++. > Compile with -fopenmp to enable OpenMP. > Online documentation: https://gcc.gnu.org/onlinedocs/libgomp/ > OpenMP support history: https://gcc.gnu.org/projects/gomp/ Nothing really changed since the last year, OpenMP 5.0 is not out yet, and OpenMP 4.5 Fortran is only partially supported even in the latest GCC versions, not fully supported. Jakub
Re: GCC Compilers info for the OpenMP Compilers page
Thank you very much for the confirmation, Jakub! Helen On Wed, Nov 8, 2017 at 4:38 AM, Jakub Jelinek wrote: > On Wed, Nov 08, 2017 at 04:28:18AM -0800, Yun He wrote: > > Jakub, Ed, and/or GCC support, > > > > Appreciate if we could get an update for GCC. SC17 is just around the > > corner. > > > > Below is what we have for now. > > > > Open Source GCC Free and open source – Linux, Solaris, AIX, MacOSX, > > Windows, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, HPUX, RTEMS > > >From GCC 4.2.0, OpenMP 2.5 is fully supported. > > >From GCC 4.4.0, OpenMP 3.0 is fully supported. > > >From GCC 4.7.0, OpenMP 3.1 is fully supported. > > In GCC 4.9.0, OpenMP 4.0 is supported for C and C++, but not Fortran. > > >From GCC 4.9.1, OpenMP 4.0 is fully supported. > > >From GCC 6.1, OpenMP 4.5 is fully supported for C and C++. > > Compile with -fopenmp to enable OpenMP. > > Online documentation: https://gcc.gnu.org/onlinedocs/libgomp/ > > OpenMP support history: https://gcc.gnu.org/projects/gomp/ > > Nothing really changed since the last year, OpenMP 5.0 is not out yet, > and OpenMP 4.5 Fortran is only partially supported even in the latest > GCC versions, not fully supported. > > Jakub >
Re: Question about generated type for common block in fortran
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).
Ciao,
Michael.
Re: Question about generated type for common block in fortran
On Wed, Nov 8, 2017 at 3:45 PM, Michael Matz 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.
gcc-6-20171108 is now available
Snapshot gcc-6-20171108 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20171108/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 254554 You'll find: gcc-6-20171108.tar.xzComplete GCC SHA256=4a5632e432aa1b2138d0abf521f041ef5dd98bf0cd836aa39ba0ded5ba47eb54 SHA1=d0263930ecb1be9f0caac796e1b1ad2169fb8de8 Diffs from 6-20171101 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
