Dropping of omp_integer_kind and omp_logical_kind

[jakub]

The change went in the exact opposite direction I was hoping for, I think usually the support library will implement the standard required library functions with just one return integer/logical kind and omp_integer_kind/omp_logical_kind allowed the implementation to specify which kind that is. Some compilers can change the default integer kind with compiler options, and while simple calling of such functions would still work if omp_lib.f90 or omp_lib.h use hardcoded integer(kind=4) or similar types of the functions, if the library functions are passed as actual arguments it might cause issues.

[tob]

To add: Many Fortran compilers allow to change the default integer kind using a command line switch such as -i8 or -fdefault-integer-8. Thus, for the compiler, two different integer kinds need to be supported, if the specification talks about "default integer kind" - or simply uses INTEGER without specifying a kind type parameter.

While when invoking the function it does not matter as any integer value is type compatible with any integer, real or complex kind. However, there is an issue if one wants to pass the function as actual argument: In that case it matters whether one has an INTEGER(4) or INTEGER(8) returning function.*

In OpenMP 3.0 the omp_lib module contained the parameters omp_integer_kind and omp_logical_kind while the header file omp_lib.h did not.

Expected:

• The integer returning function return an integer of kind omp_integer_kind instead of a default-kind integer; ditto for logical functions.
• Those kind parameters are (re)added to the module omp_lib and to the file omp_lib.h

Advantages:

• There is only one version of each OpenMP intrinsic functions, otherwise a compiler vendor had to create two versions
• The spec remains backwards compatible as OpenMP 3 had those parameters specified (albeit only for the module) and user programs might use the constants or interfaces based on the constants

* Kind numbers used for illustration purpose; while 4 and 8 are widely used, compiler with other kind numbers exists.

[james]

First, section D is non-normative, Page 311 line 6 was added to make this clear. Section 1.5 on page 17 also explicitly states that the appendices are not normative.

Second, if you look at section D.4, in the 3.0 spec, it used the term short_int which was not defined.

Third, throughout all of section 3, the normative section, there is no use of omp_integer_kind or omp_logical_kind.

Forth, the example module contained these parameters but the example omp_lib.h did not.

Fifth, we explicitly switched to using the kind=selected_int_kind() format because of the fact that the Fortran standard does not specify what size any kind number represents.

Several alternatives to "fix" these inconsistencies were considered. The committee decided to remove the offending parameters and try to make the example module and header file consistent.

In no way does this change impact an implementation in a new way. Implementations that support multiple default integer types already needed to provide generic interfaces for the library functions. In all actuality many implementations may find that this change points out a problem with their files.

Finally, an implementation is free to put anything into its modules or headers it wants, as long as the normative part of the specification is supported.