diff mbox series

OpenMP: Update gcc/fortran/*.texi

Message ID e4bd2b06-2840-39d7-225a-dd0eb7326a27@codesourcery.com
State New
Headers show
Series OpenMP: Update gcc/fortran/*.texi | expand

Commit Message

Tobias Burnus July 23, 2020, 9:51 a.m. UTC
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?)

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?

Tobias

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

Comments

Jakub Jelinek July 23, 2020, 10:06 a.m. UTC | #1
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
Thomas Koenig July 23, 2020, 10:09 a.m. UTC | #2
Hi Tobias,

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

Best regards

	Thomas
Tobias Burnus July 23, 2020, 12:45 p.m. UTC | #3
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
diff mbox series

Patch

OpenMP: Update gcc/fortran/*.texi

gcc/fortran/ChangeLog:

	* gfortran.texi (Standards): Update URL; state that OpenMP 4.5
	is supported and 5.0 is partially.
	* intrinsic.texi (OpenMP Modules): Refer also to OpenMP 5.0;
	(OMP_LIB): Add missing derived type and new named constants.

 gcc/fortran/gfortran.texi  |  4 +-
 gcc/fortran/intrinsic.texi | 96 +++++++++++++++++++++++++++++++++++++++++++---
 2 files changed, 92 insertions(+), 8 deletions(-)

diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 20fe38534d5..d927ebc4abc 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -541,8 +541,8 @@  can be found in the @ref{Fortran 2003 status}, @ref{Fortran 2008
 status} and @ref{Fortran 2018 status} sections of the documentation.
 
 Additionally, the GNU Fortran compilers supports the OpenMP specification
-(version 4.0 and most of the features of the 4.5 version,
-@url{http://openmp.org/@/wp/@/openmp-specifications/}).
+(version 4.5 and partial support of the features of the 5.0 version,
+@url{http://openmp.org/@/openmp-specifications/}).
 There also is support for the OpenACC specification (targeting
 version 2.6, @uref{http://www.openacc.org/}).  See
 @uref{https://gcc.gnu.org/wiki/OpenACC} for more information.
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index a1ecf5933ba..1b93d251509 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -15291,12 +15291,12 @@  with the following options: @code{-fno-unsafe-math-optimizations
 @section OpenMP Modules @code{OMP_LIB} and @code{OMP_LIB_KINDS}
 @table @asis
 @item @emph{Standard}:
-OpenMP Application Program Interface v4.5
+OpenMP Application Program Interface v4.5 and
+OpenMP Application Program Interface v5.0 (partially supported).
 @end table
 
-
 The OpenMP Fortran runtime library routines are provided both in
-a form of two Fortran 90 modules, named @code{OMP_LIB} and 
+a form of two Fortran modules, named @code{OMP_LIB} and
 @code{OMP_LIB_KINDS}, and in a form of a Fortran @code{include} file named
 @file{omp_lib.h}. The procedures provided by @code{OMP_LIB} can be found
 in the @ref{Top,,Introduction,libgomp,GNU Offloading and Multi
@@ -15306,19 +15306,25 @@  below.
 
 For details refer to the actual
 @uref{http://www.openmp.org/wp-content/uploads/openmp-4.5.pdf,
-OpenMP Application Program Interface v4.5}.
-And for the @code{pause}-related constants to the OpenMP 5.0 specification.
+OpenMP Application Program Interface v4.5} and
+@uref{https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf,
+OpenMP Application Program Interface v5.0}.
 
 @code{OMP_LIB_KINDS} provides the following scalar default-integer
 named constants:
 
 @table @asis
+@item @code{omp_allocator_handle_kind}
+@item @code{omp_alloctrait_key_kind}
+@item @code{omp_alloctrait_val_kind}
 @item @code{omp_lock_kind}
 @item @code{omp_lock_hint_kind}
 @item @code{omp_nest_lock_kind}
 @item @code{omp_pause_resource_kind}
+@item @code{omp_memspace_handle_kind}
 @item @code{omp_proc_bind_kind}
 @item @code{omp_sched_kind}
+@item @code{omp_sync_hint_kind}
 @end table
 
 @code{OMP_LIB} provides the scalar default-integer
@@ -15326,6 +15332,12 @@  named constant @code{openmp_version} with a value of the form
 @var{yyyymm}, where @code{yyyy} is the year and @var{mm} the month
 of the OpenMP version; for OpenMP v4.5 the value is @code{201511}.
 
+The following derived type:
+
+@table @asis
+@item @code{omp_alloctrait}
+@end table
+
 The following scalar integer named constants of the
 kind @code{omp_sched_kind}:
 
@@ -15336,7 +15348,7 @@  kind @code{omp_sched_kind}:
 @item @code{omp_sched_auto}
 @end table
 
-And the following scalar integer named constants of the 
+And the following scalar integer named constants of the
 kind @code{omp_proc_bind_kind}:
 
 @table @asis
@@ -15356,6 +15368,11 @@  kind @code{omp_lock_hint_kind}:
 @item @code{omp_lock_hint_contended}
 @item @code{omp_lock_hint_nonspeculative}
 @item @code{omp_lock_hint_speculative}
+@item @code{omp_sync_hint_none}
+@item @code{omp_sync_hint_uncontended}
+@item @code{omp_sync_hint_contended}
+@item @code{omp_sync_hint_nonspeculative}
+@item @code{omp_sync_hint_speculative}
 @end table
 
 And the following two scalar integer named constants are of the
@@ -15366,6 +15383,73 @@  kind @code{omp_pause_resource_kind}:
 @item @code{omp_pause_hard}
 @end table
 
+The following scalar integer named constants are of the kind
+@code{omp_alloctrait_key_kind}:
+
+@table @asis
+@item @code{omp_atk_sync_hint}
+@item @code{omp_atk_alignment}
+@item @code{omp_atk_access}
+@item @code{omp_atk_pool_size}
+@item @code{omp_atk_fallback}
+@item @code{omp_atk_fb_data}
+@item @code{omp_atk_pinned}
+@item @code{omp_atk_partition}
+@end table
+
+The following scalar integer named constants are of the kind
+@code{omp_alloctrait_val_kind}:
+
+@table @asis
+@code{omp_alloctrait_key_kind}:
+@item @code{omp_atv_default}
+@item @code{omp_atv_false}
+@item @code{omp_atv_true}
+@item @code{omp_atv_contended}
+@item @code{omp_atv_uncontended}
+@item @code{omp_atv_serialized}
+@item @code{omp_atv_sequential}
+@item @code{omp_atv_private}
+@item @code{omp_atv_all}
+@item @code{omp_atv_thread}
+@item @code{omp_atv_pteam}
+@item @code{omp_atv_cgroup}
+@item @code{omp_atv_default_mem_fb}
+@item @code{omp_atv_null_fb}
+@item @code{omp_atv_abort_fb}
+@item @code{omp_atv_allocator_fb}
+@item @code{omp_atv_environment}
+@item @code{omp_atv_nearest}
+@item @code{omp_atv_blocked}
+@end table
+
+The following scalar integer named constants are of the kind
+@code{omp_allocator_handle_kind}:
+
+@table @asis
+@item @code{omp_null_allocator}
+@item @code{omp_default_mem_alloc}
+@item @code{omp_large_cap_mem_alloc}
+@item @code{omp_const_mem_alloc}
+@item @code{omp_high_bw_mem_alloc}
+@item @code{omp_low_lat_mem_alloc}
+@item @code{omp_cgroup_mem_alloc}
+@item @code{omp_pteam_mem_alloc}
+@item @code{omp_thread_mem_alloc}
+@end table
+
+The following scalar integer named constants are of the kind
+@code{omp_memspace_handle_kind}:
+
+@table @asis
+@item @code{omp_default_mem_space}
+@item @code{omp_large_cap_mem_space}
+@item @code{omp_const_mem_space}
+@item @code{omp_high_bw_mem_space}
+@item @code{omp_low_lat_mem_space}
+@end table
+
+
 
 @node OpenACC Module OPENACC
 @section OpenACC Module @code{OPENACC}