Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28633 Discussions

OpenMP default(none) missing procedure pointers

MR
Beginner
660 Views
Hi all,
this is a very small comment about OpenMP "default(none)" and
procedure pointers. In fact, ifort compiles the attached code, even
though the variable pf is not specified to be either private or
shared, which seems incorrect to me.

Regards,
Marco Restelli


ifort -V
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100414 Package ID: l_cprof_p_11.1.072

[fortran]module ma
 implicit none
contains
 pure function f(x)
  real, intent(in) :: x
  real f
   f = sin(x)*cos(x)
 end function f
end module ma


program test
 use ma, only: f
 implicit none
 integer :: i
 real, dimension(1000) :: s, t
 procedure(f), pointer :: pf
 
  pf => f

  !$omp parallel do schedule(static) &
  !$omp   private(i) shared(t,s) default(none)
  do i=1,1000
    t(i) = pf(s(i))
  enddo
  !$omp end parallel do

  write(*,*) 'Sum ',sum(t)
end program test
[/fortran]
0 Kudos
5 Replies
jimdempseyatthecove
Honored Contributor III
660 Views

Marco,

Interesting.

Have you looked to see if pf were private or shared?
I think you need & on continuation line too, give it a try

!$ompparalleldoschedule(static)&

!$omp&private(i)shared(t,s)default(none)

0 Kudos
MR
Beginner
660 Views
Jim, the code compiles in all the three cases:

!$omp private(i) shared(t,s) default(none) ! incorrect, I think

!$omp private(i,pf) shared(t,s) default(none) ! correct

!$omp private(i) shared(t,s,pf) default(none) ! correct

and, as far as I can tell from a larger example, it works correctly.
My point is that the first version should not compile at all. Or,
better said, since I'm not very good at reading standards and my
example involves procedure pointers anyway, which are not in f95, I
would "somehow" expect that my example would be rejected due to the
following specification (I'm referring to "OpenMP Application Program
Interface", Version 3.0 May 2008, section 2.9.3.1)

"The default(none) clause requires that each variable that is
referenced in the construct, and that does not have a predetermined
data-sharing attribute, must have its data-sharing attribute
explicitly determined by being listed in a data-sharing attribute
clause."

Concerning continuation lines, I think that the second & is optional:
from section 2.1.2 I see

"Continued directive lines must have an ampersand as the last nonblank
character on the line, prior to any comment placed inside the
directive. Continuation directive lines can have an ampersand after
the directive sentinel with optional white space before and after the
ampersand."

Marco

0 Kudos
jimdempseyatthecove
Honored Contributor III
660 Views
Yes Marco, I understood your problem statement on the first post. My reply should have been clearer.

Your original code snip had default none on a !$OMP line following a !$OMP statement ending in & (or potentially ending in "& "). Part of my post tried to address this issue without explination.

By moving the default(none) from the continuation line to the first !$OMP line you removed any ambiguity as to if the problem involved not processing the 2nd !$OMP line as a continuation line.

The default(none) should apply to procedure pointers as well as variables/arrays/...

consider:

pf => f
!$OMP SECTIONS ... default(none)
...
!$OMP SECTION
pf => f2
...

Clearly the above will have different behaviors dependent upon if pf is shared or private.
default(none) is intended to catch ambiguities in programming by requiring you to state your intentions.

Therefore I concur withyour opinion that this is a bug.

Jim Dempsey
0 Kudos
MR
Beginner
660 Views
Jim,
OK, tank you, now I see your point. So, just to make sure, nothing
changes even by using

!$omp parallel do schedule(static) default(none) private(i) shared(t,s)

Best,
Marco

0 Kudos
jimdempseyatthecove
Honored Contributor III
660 Views
Add shared(pf) (assuming you do not modify pf inside the parallel region)

default(none) should have issued error when using pf inside parallel region (when pf not declaired as either private or shared). Although this may not be necessary with your current version of the compiler, the next version may fix the bug, and then you will get error messages. Or maybe the next person will get the error message and not know what to do.

Jim Dempsey
0 Kudos
Reply