- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The program below exits with "error" on my machine. It looks as if the variable r in the block is shared by the openmp loop, but it surely shouldn't be?
Thank you,
UM
program mfort implicit none integer :: i real :: x(1000)=[(i,i=1,1000)], y(1000) !$omp parallel do do i=1,1000 call sub(x(i),y(i)) enddo contains subroutine sub(x,y) real :: x,y,z integer :: i block real :: r r=x z=0 do i=1,1000 z=z+cos(real(i)) ! waste some time enddo if(r .ne. x) then print *,"error" stop endif y=r+z end block end subroutine end program
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What version of the compiler? And what were the command line options?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can reproduce this, but I will caution that OpenMP does not define the behavior here since it barely acknowledges Fortran 2003 and does not discuss how the BLOCK construct is handled. That said, this ought to work and I will let the developers know. Issue ID is DPD200408259. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, thanks. But just to be clear: you are saying that as soon as I use openmp parallelization, then I should stay away from any Fortran 2003 or 08 language extensions? This is a serious constraint for the development of modern scientific computing software, and I didn't see Intel acknowledge this in its documentation/advertisement, etc.
In any event, precise guidance what is/what is not supported concerning openmp and Fortran 2003/08 would be very helpful. Thank you again.
UM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The OpenMP standard is lacking in information about use of F2003 features, including BLOCK and PDTs. This example is even more problematic, with an "orphan, contained subroutine" outside the parallel region. You can find the OpenMP standard at openmp.org.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We found that the compiler is allocating R statically, which it shouldn't do if /Qopenmp is in effect (since that implies /recursive). As a workaround, add , AUTOMATIC to the declaration of R (this is an extension).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
Can you ask (and reply) if for non-contained procedures if BLOCK scalars are (incorrectly) static?
(This would make BLOCK's in general incompatible with OpenMP as well as in recursively used procedures.)
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's a peculiarity only when /Qopenmp is specified, but happens even if not a contained procedure. BLOCK is not supported by the OpenMP standard at this time. It works fine in an ordinary recursive procedure when OpenMP is not used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Let me clarify my question
Assume you have a recursive subroutine that is called by the main thread of a program that is compiled with /Qopenmp. This subroutine is never called from within a parallel region. Is then the BLOCK contained scalar variable r static?
IOW, for the time being, are we required to attribute all BLOCK local variables with AUTOMATIC? (assuming the procedure is indeed called recursively)?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you compile with /Qopenmp, then any variables declared in a BLOCK need to have the AUTOMATIC attribute added (if the block can be entered recursively or simultaneously.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK,
If this behavior ends up being standard behavior, then can you add to the documentation in bold that BLOCK declared variables including scalar are implicitly SAVE.
This makes the default/(option specified) behavior of BLOCK declared variables inconsistent with procedure declared variables.
BTW this explains why when I used BLOCK in an OpenMP program that the results got trashed.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The "declared variables are implicitly SAVE" behavior is a bug, so ... no documentation required.
Using the AUTOMATIC keyword *now* is a workaround until we resolve the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I expect the bug to be fixed in Update 1 to Parallel Studio XE 2017.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page