- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've alerted colleagues on the compiler team to look at this.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page