On Thu, Jul 23, 2020 at 11:51:38AM +0200, Tobias Burnus wrote:
> Except for a few known bugs (and a bunch of unknown ones),
> I am not aware of any outstanding issues with OpenMP 4.5.
> Additionally, the openmp_version claims 201511 (= 4.5).
> Hence, state that 4.5 is supported – and OpenMP 5.0 is
> partially.
>
> I did update the .texi file to match the current content
> of OMP_LIB.
>
> However, compared to C/C++ I do note that the 'omp_depend_kind'
> is missing, which in C/C++ omp.h is a struct of
> size "char[2*sizeof(*void)]".
> I fear that using 'integer(kind=2*c_intptr_t)' will not
> work everywhere – hence, I did not add it with this patch.
> (→ back to the drawingboard?)
First of all, libgomp isn't supported on all targets, the weirdest ones
hopefully don't have libgomp enabled.
And we can do what we do e.g. for omp_nest_lock_kind, sometimes use
indirection, but try to use large kind if possible. So unlike
omp_nest_lock_kind, I'd prefer to use kind=16 if supported.
And, unlike omp_nest_lock_kind, it is unfortunately not just the matter of
the library which can have something like OMP_NEST_LOCK_DIRECT, but the
compiler needs to agree on that.
So for now I think I'd suggest a configure test and fail libgomp build if
2*c_intptr_t kind doesn't work, and let's do something only if we discover a
target which has libgomp enabled and doesn't support those kinds.
> Otherwise, C/C++'s omp.h only has some memory allocation
> functions which currently (in OpenMP 5.0.0) do not have
> a Fortran equivalent.
>
> OK for the trunk?
Ok, thanks.
Jakub
