Not really new - but as the topic came up elsewhere (OpenMP issue 4455),
I had a second thought about this and I think it make sense to add a note.
GCC uses the OpenMP 6.0 version.
The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code'
and 'omp_interop_rc_t *ret_code'.
For C++, passing the wrong pointer type type give an error and
also passing 'int' to 'enum' gives an error (but -fpermissive turns
that one into a warning in g++ but not in clang++).
For C, gcc < 14 and clang print a -Wincompatible-pointer-types warning
by default for the pointer-type mismatch; gcc >= 14 has an error by default:
r14-6037-g9715c545d33b3a c: Turn -Wincompatible-pointer-types into a permerror
[For the non-pointer issue, the solution is just to use the enum,
for the pointer issue there is no real solution in C++ and only an
ugly for C.]
See also https://gcc.gnu.org/onlinedocs/libgomp/Interoperability-Routines.html
Comments, suggestions, remarks before I commit it?
Tobias
libgomp.texi (omp_interop_*): Add note about 5.2-to-6.0 incompatibility
GCC uses the 6.0 types - which are unfortunately not quite compatible with
code expecting 5.1/5.2 data types. Therefore, this commit adds a note to
hopefully reduce surprises. Namely:
For C/C++: while OpenMP 5.1 and 5.2 used 'int *ret_code', OpenMP 6.0 uses
'omp_interop_rc_t *ret_code' in omp_interop_{int,ptr,str} and 'int' instead
of 'omp_interop_rc_t ret_code' in omp_get_interop_rc_desc.
Neither C nor C++ like passing the wrong pointer type, albeit for C, GCC < 14
and clang only warn (gcc >= r14-6037-g9715c545d33b3a has an error) and
using -fpermissive turns it into a warning and -Wno-incompatible-pointer-types
silences it for C.
C++ also dislikes passing an int to an enum, albeit -fpermissive turns the
error into a warning with g++ (but not clang++). And, here, using an enum
on the caller side works with both int and enum on the callee side.
libgomp/ChangeLog:
* libgomp.texi (omp_interop_{int,ptr,str,rc_desc}): Add note about
'ret_code' type change in OpenMP 6.
libgomp/libgomp.texi | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 8e487bcd168..8984714ff3f 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -3128,5 +3128,6 @@ and Fortran or used with @code{NULL} as argument in C and C++. If successful,
@var{ret_code} (if present) is set to @code{omp_irc_success}.
In GCC, the effect of running this routine in a @code{target} region that is not
-the initial device is unspecified.
+the initial device is unspecified. Note that OpenMP prior to 6.0 use the type
+@code{int*} for @var{ret_code} in C/C++.
@@ -3174,5 +3175,6 @@ and Fortran or used with @code{NULL} as argument in C and C++. If successful,
@var{ret_code} (if present) is set to @code{omp_irc_success}.
In GCC, the effect of running this routine in a @code{target} region that is not
-the initial device is unspecified.
+the initial device is unspecified. Note that OpenMP prior to 6.0 use the type
+@code{int*} for @var{ret_code} in C/C++.
@@ -3220,5 +3222,6 @@ and Fortran or used with @code{NULL} as argument in C and C++. If successful,
@var{ret_code} (if present) is set to @code{omp_irc_success}.
In GCC, the effect of running this routine in a @code{target} region that is not
-the initial device is unspecified.
+the initial device is unspecified. Note that OpenMP prior to 6.0 use the type
+@code{int*} for @var{ret_code} in C/C++.
@@ -3348,6 +3351,9 @@ the @var{ret_code} in human-readable form.
The behavior is unspecified if value of @var{ret_code} was not set by an
interoperability routine invoked for @var{interop}.
+Note that OpenMP prior to 6.0 use the type @code{int} for @var{ret_code}
+in C/C++.
+
@item @emph{C/C++}:
@multitable @columnfractions .20 .80
@item @emph{Prototype}: @tab @code{const char *omp_get_interop_rc_desc(const omp_interop_t interop,
