OpenMP missing USE OMP_LIB quirk

[jimdempseyatthecove]

I posted this on Premier Support but I though it might be of interest to the other forum members.

I have an IVF threaded application using OpenMP. In a Fortran subroutine containing an !$OMP PARALLEL section, compiled with OpenMP enabled, and without IMPLICIT NONE. I erroniously left off the USE OMP_LIB. Therefore the code did not have the benefit of the function interface declarations.

Inside the parallel section a call to OMP_GET_THREAD_NUM() was made to obtain the thread team member number and the result was used in a IF test that filtered the code to execute on a given thread number.

What happens in this circumstance is the NoOpenMP stub subroutine for OMP_GET_THREAD_NUM() is called instead of the WithOpenMP subroutine for OMP_GET_THREAD_NUM() being called. (returning invalid thread number)

This is likely due to the missing ALIAS from the interface not used.

The problem with this is there is no compile error .AND. the incorrect function is called.

This particular error caused me about a week of work to root out the cause.

In light of this, I would like to recommend that the OpenMP library functions get auto interfaced with ALIAS dependent upon compilation options. i.e.

When compiling with OpenMP the interface and ALIAS are those of the OpenMP runtime system are present.

When compiling without OpenMP do nothing (treat as integer function call or error if implicit none in effect).

Jim Dempsey

[TimP]

Thread checker warns about OMP function calls without USE OMP_LIB, regardless of whether they are consistently declared. implicit none also should catch failure to declare an OMP function, regardless of whether -openmp compilation is in effect.
I agree that you have a case for the compiler to perform syntax checking on openmp calls when -openmp is on.
For openmp off, there might have to be a strict Fortran standard conformance flag which doesn't do special function call checking, and one which checks for openmp and other compiler library calls, or at least warns about calls with no interface block or module definition in scope. g77 did something like that, without interface blocks, requiring EXTERNAL declarations any time a user function happened to have the name of a library function. That approach has been rejected by all current compilers.

[jimdempseyatthecove]

Tim,

I think in this case the problem is disturbing.

When compiling with OpenMP enabled the OpenMP run time library is linked into the application. The "official" entry point name for, say, to get the thread team member number is OMP_GET_THREAD_NUM. The OpenMP standard (from my understanding) requires that if OpenMP is disabled that stub functions be supplied. In this case when OpenMP is disabled the stub function should return an otherwise invalid thread team member number such as a -number.

In this case I am compiling with OpenMP enabled but the code is being dispatched to the OpenMP _disabled_ stub function. !?!

To me, this is somewhat analogous to compiling with OpenMP enabled (and link withmulti threadedlibs) but the omission of OMP_LIB causing ALLOCATE to call the single threaded library allocate routine. Granted ALLOCATE is not declared within OMP_LIB.

What I am getting at is the entry point names for LibraryXYZsingleThreaded should be the same entry point names as LibraryXYZmultiThreaded (generally they are) and in the same manner entry point names for LibraryOpenMPenabled should be the same entry point names as LibraryOpenMPdisabled. i.e.the programmer should expect the same dispatching behavior (dispatched to the library specified for link).

Jim Dempsey