Re: [Patch] OpenMP: Update gcc/fortran/*.texi

[Tobias Burnus]

Hi Thomas,

On 7/23/20 12:09 PM, Thomas Koenig wrote:

can you also update https://gcc.gnu.org/gcc-11/changes.html ?

do you mind if I put it on the backburner? I think there will be several
more OpenMP changes during GCC 11 and I hope that one can then write a
final status which will be: officially support OpenMP 4.5 support (now
also) for Fortran plus a large chunk of 5.0/5.1 for C/C++/Fortran. –
That seems to be simpler than keeping updating the changes.html.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: [Patch] OpenMP: Update gcc/fortran/*.texi

[Thomas Koenig via Gcc-patches]

Hi Tobias,

can you also update https://gcc.gnu.org/gcc-11/changes.html ?

Best regards

Thomas

Re: [Patch] OpenMP: Update gcc/fortran/*.texi

[Jakub Jelinek via Gcc-patches]

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