topic I suppose that openmp_version in Intel® Fortran Compiler

OpenMP bugs

Brian1 — Tue, 11 Jun 2013 03:41:12 GMT

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:

[fortran]

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

[/fortran]

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:

[fortran]

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

[/fortran]

I suppose that openmp_version

TimP — Tue, 11 Jun 2013 13:16:36 GMT

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

Brian1 — Wed, 12 Jun 2013 03:26:29 GMT

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:

[fortran]

module omp_lib_kinds

use, intrinsic :: iso_c_binding

private

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

[/fortran]

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

TimP — Thu, 18 Jul 2013 21:28:12 GMT

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