Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

OpenMP bugs

Brian1
Beginner
778 Views

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]

0 Kudos
3 Replies
TimP
Honored Contributor III
778 Views

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.

0 Kudos
Brian1
Beginner
778 Views

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.

0 Kudos
TimP
Honored Contributor III
778 Views

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

0 Kudos
Reply