GNU versus Intel/PGI OpenMP inconsistency

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

GNU versus Intel/PGI OpenMP inconsistency

gcc - fortran mailing list
Hi gfortran team,

I would like to bring to your attention an inconsistency between the GNU and the Intel/PGI compilers regarding the handling of "associate" variables in OpenMP constructs. Take the following code snippet:

program openmp_gnu

   use omp_lib

   implicit none
   integer :: X, Z
   integer :: i, N

   X = 1
   Z = 0
   N = 10

   associate( Y => X )

#ifdef __GFORTRAN__
!$OMP parallel do default(none) shared(N) private(i,Z)
#else
!$OMP parallel do default(none) shared(N,Y) private(i,Z)
#endif
      do i=1,N
         Z = Z + Y
      enddo

   end associate

end program openmp_gnu

Y is an associate variable (pointer) used in an OpenMP threaded environment which requires all variables to be specified explicitly. For GNU (I tested versions 6.2 to 9.1), I have to omit listing Y in the shared or private clause. If I don't, I get:

heinzeller-lt:openmp_gnu dom.heinzeller$ gfortran -fopenmp openmp_gnu.F90
openmp_gnu.F90:18:41:

   18 | !$OMP parallel do default(none) shared(N,Y) private(i,Z)
      |                                         1

For Intel (15 to 19) and PGI (17), I must list Y in either the shared or private clause, otherwise I get:

[Dom.Heinzeller@tfe08 openmp_gnu]$ ifort -openmp openmp_gnu.F90
openmp_gnu.F90(17): error #6752: Since the OpenMP* DEFAULT(NONE) clause applies, the PRIVATE, SHARED, REDUCTION, FIRSTPRIVATE, or LASTPRIVATE attribute must be explicitly specified for every variable.   [Y]
         Z = Z + Y
-----------------^
compilation aborted for openmp_gnu.F90 (code 1)

I believe that Intel and PGI are doing the right thing here - but I would like to get your feedback on whether this is true, and if yes, how we can go about fixing it.

We have an awful lot of these ifdef statements in our codebase because of this inconsistency between the various compilers, and we want to get rid of them as quickly as we can. I will also try to post this on the OpenMP forum.

Thanks very much in advance for your insight,

Dom

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GNU versus Intel/PGI OpenMP inconsistency

Toon Moene-3
On 9/27/19 6:19 PM, Dominikus Heinzeller - NOAA Affiliate via fortran wrote:

> program openmp_gnu
>
>     use omp_lib
>
>     implicit none
>     integer :: X, Z
>     integer :: i, N
>
>     X = 1
>     Z = 0
>     N = 10
>
>     associate( Y => X )
>
> #ifdef __GFORTRAN__
> !$OMP parallel do default(none) shared(N) private(i,Z)
> #else
> !$OMP parallel do default(none) shared(N,Y) private(i,Z)
> #endif
>        do i=1,N
>           Z = Z + Y
>        enddo
>
>     end associate
>
> end program openmp_gnu

I have no problem compiling this source code without the ifdef part,
i.e. with the single line:

!$OMP parallel do default(none) shared(N,Y) private(i,Z)

using gfortran 9.2:

toon@moene:~/src$ gfortran -v -c h.F90
Using built-in specs.
COLLECT_GCC=gfortran
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-8'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190909 (Debian 9.2.1-8)
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
  /usr/lib/gcc/x86_64-linux-gnu/9/f951 h.F90 -cpp=/tmp/ccq2TVsk.f90
-quiet -v -imultiarch x86_64-linux-gnu h.F90 -quiet -dumpbase h.F90
-mtune=generic -march=x86-64 -auxbase h -version
-fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/9/finclude -o
/tmp/ccBp7fo9.s
GNU Fortran (Debian 9.2.1-8) version 9.2.1 20190909 (x86_64-linux-gnu)
        compiled by GNU C version 9.2.1 20190909, GMP version 6.1.2, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/lib/gcc/x86_64-linux-gnu/9/finclude
  /usr/lib/gcc/x86_64-linux-gnu/9/include
  /usr/local/include
  /usr/lib/gcc/x86_64-linux-gnu/9/include-fixed
  /usr/include/x86_64-linux-gnu
  /usr/include
End of search list.
GNU Fortran2008 (Debian 9.2.1-8) version 9.2.1 20190909 (x86_64-linux-gnu)
        compiled by GNU C version 9.2.1 20190909, GMP version 6.1.2, MPFR
version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
  as -v --64 -o h.o /tmp/ccBp7fo9.s
GNU assembler version 2.32.51 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.32.51.20190909
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'

Kind regards,

--
Toon Moene - e-mail: [hidden email] - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Reply | Threaded
Open this post in threaded view
|

Re: GNU versus Intel/PGI OpenMP inconsistency

gcc - fortran mailing list
Thanks for your quick reply, Toon.

But I guess you need to use the "-fopenmp" flag to activate the pragmas?

Dom

> On Sep 27, 2019, at 11:33 AM, Toon Moene <[hidden email]> wrote:
>
> On 9/27/19 6:19 PM, Dominikus Heinzeller - NOAA Affiliate via fortran wrote:
>
>> program openmp_gnu
>>    use omp_lib
>>    implicit none
>>    integer :: X, Z
>>    integer :: i, N
>>    X = 1
>>    Z = 0
>>    N = 10
>>    associate( Y => X )
>> #ifdef __GFORTRAN__
>> !$OMP parallel do default(none) shared(N) private(i,Z)
>> #else
>> !$OMP parallel do default(none) shared(N,Y) private(i,Z)
>> #endif
>>       do i=1,N
>>          Z = Z + Y
>>       enddo
>>    end associate
>> end program openmp_gnu
>
> I have no problem compiling this source code without the ifdef part, i.e. with the single line:
>
> !$OMP parallel do default(none) shared(N,Y) private(i,Z)
>
> using gfortran 9.2:
>
> toon@moene:~/src$ gfortran -v -c h.F90
> Using built-in specs.
> COLLECT_GCC=gfortran
> OFFLOAD_TARGET_NAMES=nvptx-none:hsa
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-8' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 9.2.1 20190909 (Debian 9.2.1-8)
> COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
> /usr/lib/gcc/x86_64-linux-gnu/9/f951 h.F90 -cpp=/tmp/ccq2TVsk.f90 -quiet -v -imultiarch x86_64-linux-gnu h.F90 -quiet -dumpbase h.F90 -mtune=generic -march=x86-64 -auxbase h -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/9/finclude -o /tmp/ccBp7fo9.s
> GNU Fortran (Debian 9.2.1-8) version 9.2.1 20190909 (x86_64-linux-gnu)
> compiled by GNU C version 9.2.1 20190909, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP
>
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
> ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/gcc/x86_64-linux-gnu/9/finclude
> /usr/lib/gcc/x86_64-linux-gnu/9/include
> /usr/local/include
> /usr/lib/gcc/x86_64-linux-gnu/9/include-fixed
> /usr/include/x86_64-linux-gnu
> /usr/include
> End of search list.
> GNU Fortran2008 (Debian 9.2.1-8) version 9.2.1 20190909 (x86_64-linux-gnu)
> compiled by GNU C version 9.2.1 20190909, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP
>
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
> as -v --64 -o h.o /tmp/ccBp7fo9.s
> GNU assembler version 2.32.51 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.32.51.20190909
> COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/
> LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/9/../../../:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
>
> Kind regards,
>
> --
> Toon Moene - e-mail: [hidden email] - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
> Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news


smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GNU versus Intel/PGI OpenMP inconsistency

Steve Kargl
In reply to this post by Toon Moene-3
On Fri, Sep 27, 2019 at 07:33:32PM +0200, Toon Moene wrote:

> On 9/27/19 6:19 PM, Dominikus Heinzeller - NOAA Affiliate via fortran wrote:
>
> > program openmp_gnu
> >
> >     use omp_lib
> >
> >     implicit none
> >     integer :: X, Z
> >     integer :: i, N
> >
> >     X = 1
> >     Z = 0
> >     N = 10
> >
> >     associate( Y => X )
> >
> > #ifdef __GFORTRAN__
> > !$OMP parallel do default(none) shared(N) private(i,Z)
> > #else
> > !$OMP parallel do default(none) shared(N,Y) private(i,Z)
> > #endif
> >        do i=1,N
> >           Z = Z + Y
> >        enddo
> >
> >     end associate
> >
> > end program openmp_gnu
>
> I have no problem compiling this source code without the ifdef part,
> i.e. with the single line:
>
> !$OMP parallel do default(none) shared(N,Y) private(i,Z)
>
> using gfortran 9.2:
>
> toon@moene:~/src$ gfortran -v -c h.F90

You forgot the -fopenmp option.

% gfcx -c -fopenmp a.f90
a.f90:15:41:

   15 | !$OMP parallel do default(none) shared(N,Y) private(i,Z)
      |                                         1
Error: ASSOCIATE name 'y' in SHARED clause at (1)

This untested patch allows the code to compile (watch for
cut-n-paste tab corruption).

Index: gcc/fortran/openmp.c
===================================================================
--- gcc/fortran/openmp.c        (revision 276157)
+++ gcc/fortran/openmp.c        (working copy)
@@ -4360,7 +4360,8 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *
                if (n->sym->attr.cray_pointee)
                  gfc_error ("Cray pointee %qs in SHARED clause at %L",
                            n->sym->name, &n->where);
-               if (n->sym->attr.associate_var)
+               if (n->sym->attr.associate_var
+                   && n->sym->assoc && !n->sym->assoc->variable)
                  gfc_error ("ASSOCIATE name %qs in SHARED clause at %L",
                             n->sym->name, &n->where);
              }


--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: GNU versus Intel/PGI OpenMP inconsistency

gcc - fortran mailing list
Great, thanks Steve.

Do you think this patch can be included in one of the upcoming releases?

Best,

Dom

> On Sep 27, 2019, at 11:52 AM, Steve Kargl <[hidden email]> wrote:
>
> On Fri, Sep 27, 2019 at 07:33:32PM +0200, Toon Moene wrote:
>> On 9/27/19 6:19 PM, Dominikus Heinzeller - NOAA Affiliate via fortran wrote:
>>
>>> program openmp_gnu
>>>
>>>    use omp_lib
>>>
>>>    implicit none
>>>    integer :: X, Z
>>>    integer :: i, N
>>>
>>>    X = 1
>>>    Z = 0
>>>    N = 10
>>>
>>>    associate( Y => X )
>>>
>>> #ifdef __GFORTRAN__
>>> !$OMP parallel do default(none) shared(N) private(i,Z)
>>> #else
>>> !$OMP parallel do default(none) shared(N,Y) private(i,Z)
>>> #endif
>>>       do i=1,N
>>>          Z = Z + Y
>>>       enddo
>>>
>>>    end associate
>>>
>>> end program openmp_gnu
>>
>> I have no problem compiling this source code without the ifdef part,
>> i.e. with the single line:
>>
>> !$OMP parallel do default(none) shared(N,Y) private(i,Z)
>>
>> using gfortran 9.2:
>>
>> toon@moene:~/src$ gfortran -v -c h.F90
>
> You forgot the -fopenmp option.
>
> % gfcx -c -fopenmp a.f90
> a.f90:15:41:
>
>   15 | !$OMP parallel do default(none) shared(N,Y) private(i,Z)
>      |                                         1
> Error: ASSOCIATE name 'y' in SHARED clause at (1)
>
> This untested patch allows the code to compile (watch for
> cut-n-paste tab corruption).
>
> Index: gcc/fortran/openmp.c
> ===================================================================
> --- gcc/fortran/openmp.c        (revision 276157)
> +++ gcc/fortran/openmp.c        (working copy)
> @@ -4360,7 +4360,8 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *
>                if (n->sym->attr.cray_pointee)
>                  gfc_error ("Cray pointee %qs in SHARED clause at %L",
>                            n->sym->name, &n->where);
> -               if (n->sym->attr.associate_var)
> +               if (n->sym->attr.associate_var
> +                   && n->sym->assoc && !n->sym->assoc->variable)
>                  gfc_error ("ASSOCIATE name %qs in SHARED clause at %L",
>                             n->sym->name, &n->where);
>              }
>
>
> --
> Steve


smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GNU versus Intel/PGI OpenMP inconsistency

Steve Kargl
The patch is untested.  I don't use OpenMP, so cannot
test it beyond what is in gfortran's testsuite.  After
reading parts of OpenMP 4.5 and 5.0 specs and F2018's
description of ASSOCIATE, I'm not convinced the patch
is correct.  Part of the problem is that OpenMP refers
to storage areas of items in the SHARES(list), and I
cannot determine in my briefy survey of F2018 what this
means in the context of an associate-name (i.e, your Y).
If Jakub (or other gfortran committer) wants to test
and commit, I'll leave it up to them.

--
steve


On Fri, Sep 27, 2019 at 11:55:33AM -0600, Dominikus Heinzeller - NOAA Affiliate wrote:

> Great, thanks Steve.
>
> Do you think this patch can be included in one of the upcoming releases?
>
> Best,
>
> Dom
>
> > On Sep 27, 2019, at 11:52 AM, Steve Kargl <[hidden email]> wrote:
> >
> > On Fri, Sep 27, 2019 at 07:33:32PM +0200, Toon Moene wrote:
> >> On 9/27/19 6:19 PM, Dominikus Heinzeller - NOAA Affiliate via fortran wrote:
> >>
> >>> program openmp_gnu
> >>>
> >>>    use omp_lib
> >>>
> >>>    implicit none
> >>>    integer :: X, Z
> >>>    integer :: i, N
> >>>
> >>>    X = 1
> >>>    Z = 0
> >>>    N = 10
> >>>
> >>>    associate( Y => X )
> >>>
> >>> #ifdef __GFORTRAN__
> >>> !$OMP parallel do default(none) shared(N) private(i,Z)
> >>> #else
> >>> !$OMP parallel do default(none) shared(N,Y) private(i,Z)
> >>> #endif
> >>>       do i=1,N
> >>>          Z = Z + Y
> >>>       enddo
> >>>
> >>>    end associate
> >>>
> >>> end program openmp_gnu
> >>
> >> I have no problem compiling this source code without the ifdef part,
> >> i.e. with the single line:
> >>
> >> !$OMP parallel do default(none) shared(N,Y) private(i,Z)
> >>
> >> using gfortran 9.2:
> >>
> >> toon@moene:~/src$ gfortran -v -c h.F90
> >
> > You forgot the -fopenmp option.
> >
> > % gfcx -c -fopenmp a.f90
> > a.f90:15:41:
> >
> >   15 | !$OMP parallel do default(none) shared(N,Y) private(i,Z)
> >      |                                         1
> > Error: ASSOCIATE name 'y' in SHARED clause at (1)
> >
> > This untested patch allows the code to compile (watch for
> > cut-n-paste tab corruption).
> >
> > Index: gcc/fortran/openmp.c
> > ===================================================================
> > --- gcc/fortran/openmp.c        (revision 276157)
> > +++ gcc/fortran/openmp.c        (working copy)
> > @@ -4360,7 +4360,8 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *
> >                if (n->sym->attr.cray_pointee)
> >                  gfc_error ("Cray pointee %qs in SHARED clause at %L",
> >                            n->sym->name, &n->where);
> > -               if (n->sym->attr.associate_var)
> > +               if (n->sym->attr.associate_var
> > +                   && n->sym->assoc && !n->sym->assoc->variable)
> >                  gfc_error ("ASSOCIATE name %qs in SHARED clause at %L",
> >                             n->sym->name, &n->where);
> >              }
> >
> >
> > --
> > Steve
>



--
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Reply | Threaded
Open this post in threaded view
|

Re: GNU versus Intel/PGI OpenMP inconsistency

Toon Moene-3
On 9/27/19 8:19 PM, Steve Kargl wrote:

> The patch is untested.  I don't use OpenMP, so cannot
> test it beyond what is in gfortran's testsuite.  After
> reading parts of OpenMP 4.5 and 5.0 specs and F2018's
> description of ASSOCIATE, I'm not convinced the patch
> is correct.  Part of the problem is that OpenMP refers
> to storage areas of items in the SHARES(list), and I
> cannot determine in my briefy survey of F2018 what this
> means in the context of an associate-name (i.e, your Y).
> If Jakub (or other gfortran committer) wants to test
> and commit, I'll leave it up to them.
>
Good analysis - thanks, Steve.

I think the relevant restriction for SHARED in the OpenMP standards is this:

"A variable that is part of another variable (as an array, structure
element or type parameter inquiry) cannot appear in a shared clause."

So the way to check this for ASSOCIATE names is to descend into their
declaration ... which might be complicated, because ASSOCIATE constructs
can be nested.

I cc'd Jakub, in case he wants to chime in.

Kind regards,

--
Toon Moene - e-mail: [hidden email] - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Reply | Threaded
Open this post in threaded view
|

Re: GNU versus Intel/PGI OpenMP inconsistency

Jakub Jelinek
On Fri, Sep 27, 2019 at 09:42:40PM +0200, Toon Moene wrote:

> On 9/27/19 8:19 PM, Steve Kargl wrote:
>
> > The patch is untested.  I don't use OpenMP, so cannot
> > test it beyond what is in gfortran's testsuite.  After
> > reading parts of OpenMP 4.5 and 5.0 specs and F2018's
> > description of ASSOCIATE, I'm not convinced the patch
> > is correct.  Part of the problem is that OpenMP refers
> > to storage areas of items in the SHARES(list), and I
> > cannot determine in my briefy survey of F2018 what this
> > means in the context of an associate-name (i.e, your Y).
> > If Jakub (or other gfortran committer) wants to test
> > and commit, I'll leave it up to them.
> >
> Good analysis - thanks, Steve.
>
> I think the relevant restriction for SHARED in the OpenMP standards is this:
>
> "A variable that is part of another variable (as an array, structure element
> or type parameter inquiry) cannot appear in a shared clause."
>
> So the way to check this for ASSOCIATE names is to descend into their
> declaration ... which might be complicated, because ASSOCIATE constructs can
> be nested.
>
> I cc'd Jakub, in case he wants to chime in.

I believe the gfortran behavior is correct and Intel/PGI are wrong,
I had similar discussion about this back in July.
E.g. OpenMP 5.0 says (4.5 has similar wording):
Certain variables and objects have predetermined data-sharing attributes as follows:
...
An associate name preserves the association with the selector established at the ASSOCIATE or
SELECT TYPE statement.
...
Variables with predetermined data-sharing attributes may not be listed in data-sharing attribute
clauses, except for the cases listed below.
...
and the list below the last sentence doesn't talk about those, so there is
no exception for that and thus they have predetermined data-sharing and
can't be specified explicitly, which is what gfortran diagnoses.

        Jakub
Reply | Threaded
Open this post in threaded view
|

Re: GNU versus Intel/PGI OpenMP inconsistency

gcc - fortran mailing list
Thanks, Jakub, for your assessment. I will forward this to the Intel Compiler team. Let's see what they say ... thanks all for your quick help. Best, Dom

> On Sep 27, 2019, at 2:09 PM, Jakub Jelinek <[hidden email]> wrote:
>
> On Fri, Sep 27, 2019 at 09:42:40PM +0200, Toon Moene wrote:
>> On 9/27/19 8:19 PM, Steve Kargl wrote:
>>
>>> The patch is untested.  I don't use OpenMP, so cannot
>>> test it beyond what is in gfortran's testsuite.  After
>>> reading parts of OpenMP 4.5 and 5.0 specs and F2018's
>>> description of ASSOCIATE, I'm not convinced the patch
>>> is correct.  Part of the problem is that OpenMP refers
>>> to storage areas of items in the SHARES(list), and I
>>> cannot determine in my briefy survey of F2018 what this
>>> means in the context of an associate-name (i.e, your Y).
>>> If Jakub (or other gfortran committer) wants to test
>>> and commit, I'll leave it up to them.
>>>
>> Good analysis - thanks, Steve.
>>
>> I think the relevant restriction for SHARED in the OpenMP standards is this:
>>
>> "A variable that is part of another variable (as an array, structure element
>> or type parameter inquiry) cannot appear in a shared clause."
>>
>> So the way to check this for ASSOCIATE names is to descend into their
>> declaration ... which might be complicated, because ASSOCIATE constructs can
>> be nested.
>>
>> I cc'd Jakub, in case he wants to chime in.
>
> I believe the gfortran behavior is correct and Intel/PGI are wrong,
> I had similar discussion about this back in July.
> E.g. OpenMP 5.0 says (4.5 has similar wording):
> Certain variables and objects have predetermined data-sharing attributes as follows:
> ...
> An associate name preserves the association with the selector established at the ASSOCIATE or
> SELECT TYPE statement.
> ...
> Variables with predetermined data-sharing attributes may not be listed in data-sharing attribute
> clauses, except for the cases listed below.
> ...
> and the list below the last sentence doesn't talk about those, so there is
> no exception for that and thus they have predetermined data-sharing and
> can't be specified explicitly, which is what gfortran diagnoses.
>
> Jakub


smime.p7s (2K) Download Attachment