OpenMP bugs

OpenMP bugs

I believe I have found two minor bugs in the Intel Fortran OpenMP implementation.

First, the omp_lib module "leaks" the contents of the iso_c_binding module.  This trivial program fails to compile:

program openmp_name_leak_bug
use omp_lib
implicit none
real :: c_double, c_int
end program

Second, the argument names of many of the OpenMP runtime library subprograms differ from those specified in the OpenMP standard (as required by p. 114, lines 17-22 of the OpenMP 3.1 specification).  This makes it impossible to call the affected subprograms using keyword arguments, which is expected to work if the OpenMP runtime library subprograms have explicit interfaces.  This affects both the omp_lib module and the omp_lib.h include file, since both declare explicit interfaces.  For example, this fails to compile:

program openmp_keyword_argument_bug
use omp_lib
implicit none
integer(omp_lock_kind) :: lock
call omp_set_dynamic(dynamic_threads=.true.)
call omp_set_num_threads(num_threads=1)
call omp_set_lock(svar=lock)
end program

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I suppose that openmp_version parameter value setting of 201107 is a bug when the compiler doesn't support OpenMP 3.1.

I haven't seen these issues included among the OpenMP 3.1 standard compatibility issues planned to be dealt with for OpenMP 4.0.

I'm not sure what you are getting at with respect to OpenMP 3.1.

The first bug is caused by missing public and private declarations.  It  can easily be fixed by changing the code for the omp_lib_kinds module in omp_lib.f90 to:

module omp_lib_kinds
use, intrinsic :: iso_c_binding
integer, parameter, public :: omp_integer_kind = c_int
 integer, parameter, public :: omp_logical_kind = 4
 integer, parameter, public :: omp_real_kind = c_float
 integer, parameter, public :: kmp_double_kind = c_double
 integer, parameter, public :: omp_lock_kind = c_intptr_t
 integer, parameter, public :: omp_nest_lock_kind = c_intptr_t
 integer, parameter, public :: omp_sched_kind = omp_integer_kind
 integer, parameter, public :: kmp_pointer_kind = c_intptr_t
 integer, parameter, public :: kmp_size_t_kind = c_size_t
 integer, parameter, public :: kmp_affinity_mask_kind = c_intptr_t
end module omp_lib_kinds

The second bug is an issue with respect to both the OpenMP 3.0, 3.1, and the draft 4.0 standards.  It is arguably an issue with respect to the lock routines in the OpenMP 2.0 Fortran standard, where the names "svar" and "nvar" are shown as arguments for these routines.  Again, the fix here is trivial to implement: just change the argument names in the interfaces declared in omp_lib.f90 to the names shown in the standard.

I've alerted colleagues on the compiler team to look at this.

Leave a Comment

Please sign in to add a comment. Not a member? Join today