I ran into a problem with the intel fortran compiler on windows.
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 184.108.40.2061 Build 20201010_000000
Here is a small program that illustrates the problem (OMPBug.f90):
!===================================================================== MODULE recTaskCall CONTAINS SUBROUTINE rec_in (nlevels) INTEGER :: nlevels !$OMP PARALLEL SHARED(nlevels) DEFAULT(NONE) !$OMP SINGLE CALL rec_low(0) !$OMP END SINGLE !$OMP END PARALLEL CONTAINS RECURSIVE SUBROUTINE rec_low(idepth) INTEGER :: idepth IF (idepth== nlevels) RETURN !$OMP TASK CALL rec_low(idepth+1) !$OMP END TASK END SUBROUTINE END SUBROUTINE END MODULE PROGRAM testme USE recTaskCall CALL rec_in(3) END PROGRAM !============================================================
After compiling the program with
ifort OMPBug.f90 /traceback /Qopenmp /debug
and running the exe, I get an access violation when nlevels is accessed from the call to rec_in within the openmp task construct.
It worked with gfortran and I did not get a compile time error so I assume this is valid code,... I might be wrong. However, it seems that with the intel compiler the host association is lost within the openmp construct.
Is there an obvious solution I am missing? I am aware, that I can pass nlevels and the problem goes away. However, with the variables in my real code this strategy leads to a stackoverflow that is not easily fixed.
Unfortunately, copy/paste isn't working for me to grab your code.
Does your small program work if you compile with /Qopenmp-stubs? That turns your program into a sequential program. It's a handy compiler option for debugging OpenMP applications.
When you compile without Qopenmp, the OpenMP directives are considered comments and ignored.
When compiling with Qopenmp and the stubs library the OpenMP directives are processed and the stubs library is actually used and the app runs serially.