- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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]
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
!$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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page