[Patch] libgomp.texi: Add OpenMP Implementation Status

[Patch] libgomp.texi: Add OpenMP Implementation Status

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

Hi Jakub, hi all,

as the issue came up from time to time, I thought it
makes sense to add an implementation status.

I settled on putting it into libgomp.texi instead of
a webpage or another location.

The 5.1 section should be fine – except for additional
items. OpenMP 5.0 has stub wordings and needs to be filled.
The version in the patch should be sufficient for now
but it would be nice to have it completed before GCC 12.
(Or even before the BoF in two weeks or OpenMP Con in
a week, hmm.)

OK? Comments? Typo/wording fixes?

Tobias

PS: Besides the OpenMP implementation status, also:
* implementation details/choices could be added.
* some hints regarding tricks & tips related to OpenMP
   and in particular offloading
   (e.g. -foffload-options=-latomic might be needed for nvptx*)
* user-friendlier documentation how to build the offload compiler.
   (The offloading wiki page has too many internals and
   lacks a step-by-step guide.)
Not all should be in libgomp.texi, however.

(* Side note: it is mentioned indirectly: as example in
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload )

Currently, the OpenMP/offloading documentation is spread over:

* libgomp: https://gcc.gnu.org/onlinedocs/libgomp/
* gcc: https://gcc.gnu.org/onlinedocs/gcc/
   flags (-fopenmp(-simd), -foffload(-options=), ...)
* gfortran: OpenMP + OpenMP Modules omp_lib and omp_lib_kinds
   (and likewise for OpenACC) https://gcc.gnu.org/onlinedocs/gfortran/
* Project page: https://gcc.gnu.org/projects/gomp/
* Wiki page: https://gcc.gnu.org/wiki/openmp
   (likewise: https://gcc.gnu.org/wiki/OpenACC
   and also: https://gcc.gnu.org/wiki/OpenACC/Implementation%20Status )
* Offloading: https://gcc.gnu.org/wiki/Offloading
   plus https://gcc.gnu.org/wiki/nvptx
   plus configure-time options at https://gcc.gnu.org/install/configure.html

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Attachment #2: omp-status.diff --]
[-- Type: text/x-patch, Size: 6282 bytes --]

libgomp.texi: Add OpenMP Implementation Status

libgomp/
	* libgomp.texi (Enabling OpenMP): Refer to OMP spec in general
	not to 4.5; link to new section.
	(OpenMP Implementation Status): New.

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 1bfa26ea497..94c8de07cb3 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -95,6 +95,7 @@ changed to GNU Offloading and Multi Processing Runtime Library.
 @comment
 @menu
 * Enabling OpenMP::            How to enable OpenMP for your applications.
+* OpenMP Implementation Status:: List of implemented features by OpenMP version
 * OpenMP Runtime Library Routines: Runtime Library Routines.
                                The OpenMP runtime application programming
                                interface.
@@ -141,9 +142,113 @@ flag @command{-fopenmp} must be specified.  This enables the OpenMP directive
 arranges for automatic linking of the OpenMP runtime library 
 (@ref{Runtime Library Routines}).
 
-A complete description of all OpenMP directives accepted may be found in 
-the @uref{https://www.openmp.org, OpenMP Application Program Interface} manual,
-version 4.5.
+A complete description of all OpenMP directives may be found in the
+@uref{https://www.openmp.org, OpenMP Application Program Interface} manuals.
+See also @ref{OpenMP Implementation Status}.
+
+
+@c ---------------------------------------------------------------------
+@c OpenMP Implementation Status
+@c ---------------------------------------------------------------------
+
+@node OpenMP Implementation Status
+@chapter OpenMP Implementation Status
+
+@menu
+* OpenMP 4.5:: Feature completion status to 4.5 specification
+* OpenMP 5.0:: Feature completion status to 5.0 specification
+* OpenMP 5.1:: Feature completion status to 5.1 specification
+@end menu
+
+The @code{_OPENMP} preprocessor macro and Fortran's @code{openmp_version}
+parameter, provided by @code{omp_lib.h} and the @code{omp_lib} module, have
+the value @code{201511} (i.e. OpenMP 4.5).
+
+@node OpenMP 4.5
+@section OpenMP 4.5
+
+The OpenMP 4.5 specification is fully supported.
+
+@node OpenMP 5.0
+@section OpenMP 5.0
+
+Partial support of the OpenMP 5.0 specification. The OMPT and the OMPD
+interfaces are unsupported.
+
+@node OpenMP 5.1
+@section OpenMP 5.1
+
+@unnumberedsubsec New features listed in Appendix B of the OpenMP specification
+
+@multitable @columnfractions .60 .10 .25
+@headitem Description @tab Status @tab Comments
+@item OpenMP directive as C++ attribute specifiers @tab Y @tab
+@item @code{omp_all_memory} reserved locator @tab N @tab
+@item @emph{target_device trait} in OpenMP Context @tab N @tab
+@item @code{target_device} selector set in context selectors @tab N @tab
+@item C/C++'s @code{declare variante} directive: elision support of
+      preprocessed code @tab N @tab
+@item @code{declare variante}: new clauses @code{adjust_args} and
+      @code{append_args} @tab N @tab
+@item @code{dispatch} construct @tab N @tab
+@item device-specific ICV settings the environment variables @tab N @tab
+@item assume directive @tab N @tab
+@item @code{nothing} directive @tab Y @tab
+@item @code{error} directive @tab Y @tab
+@item @code{masked} construct @tab Y @tab
+@item @code{scope} directive @tab Y @tab
+@item Loop transformation constructs @tab N @tab
+@item @code{strict} modifier in the @code{grainsize} and @code{num_tasks}
+      clauses of the taskloop construct @tab Y @tab
+@item @code{align} clause/modifier in @code{allocate} directive/clause
+      and @code{allocator} directive @tab N @tab
+@item @code{thread_limit} clause to @code{target} construct @tab N @tab
+@item @code{has_device_addr} clause to @code{target} construct @tab N @tab
+@item iterators in @code{target update} motion clauses and @code{map}
+      clauses @tab N @tab
+@item indirect calls to the device version of a procedure or function in
+      @code{target} regions @tab N @tab
+@item @code{interop} directive @tab N @tab
+@item @code{omp_interop_t} object support in runtime routines @tab N @tab
+@item @code{nowait} clause in @code{taskwait} directive @tab N @tab
+@item Extensions to the @code{atomic} directive @tab N @tab
+@item @code{seq_cst} clause on a @code{flush} construct @tab N @tab
+@item @code{inoutset} argument to the @code{depend} clause @tab N @tab
+@item @code{private} and @code{firstprivate} argument to @code{default}
+      clause in C and C++ @tab N @tab
+@item @code{present} argument to @code{defaultmap} clause @tab N @tab
+@item @code{omp_set_num_teams}, @code{omp_set_teams_thread_limit},
+      @code{omp_get_max_teams}, @code{omp_get_teams_thread_limit} runtime
+      routines @tab N @tab
+@item @code{omp_target_is_accessible} runtime routine @tab N @tab
+@item @code{omp_target_memcpy_async} and @code{omp_target_memcpy_rect_async}
+      runtime routines @tab N @tab
+@item @code{omp_get_mapped_ptr} runtime routine @tab N @tab
+@item @code{omp_calloc}, @code{omp_realloc}, @code{omp_aligned_alloc} and
+      @code{omp_aligned_calloc} runtime routines @tab N @tab
+@item @code{omp_alloctrait_key_t} enum: @code{omp_atv_serialized} added,
+      @code{omp_atv_default} changed @tab Y @tab
+@item @code{omp_display_env} runtime routine @tab P
+      @tab Not inside @code{target} regions
+@item @code{ompt_scope_endpoint_t} enum: @code{ompt_scope_beginend} @tab N @tab
+@item @code{ompt_sync_region_t} enum additions @tab N @tab
+@item @code{ompt_state_t} enum: @code{ompt_state_wait_barrier_implementation}
+      and @code{ompt_state_wait_barrier_teams} @tab N @tab
+@item @code{ompt_callback_target_data_op_emi_t},
+      @code{ompt_callback_target_emi_t}, @code{ompt_callback_target_map_emi_t}
+      and @code{ompt_callback_target_submit_emi_t} @tab N @tab
+@item @code{ompt_callback_error_t} type @tab N @tab
+@item @code{OMP_PLACES} syntax was extension @tab N @tab
+@item @code{OMP_NUM_TEAMS} and @code{OMP_TEAMS_THREAD_LIMIT} environment
+      variables @tab N @tab
+@end multitable
+
+@unnumberedsubsec Other new OpenMP 5.1 features
+
+@multitable @columnfractions .60 .10 .25
+@headitem Description @tab Status @tab Comments
+@item Suppport of strictly structured blocks in Fortran @tab N @tab
+@end multitable
 
 
 @c ---------------------------------------------------------------------

Re: [Patch] libgomp.texi: Add OpenMP Implementation Status

[Jakub Jelinek]

On Mon, Sep 06, 2021 at 06:48:25PM +0200, Tobias Burnus wrote:
> Hi Jakub, hi all,
> 
> as the issue came up from time to time, I thought it
> makes sense to add an implementation status.
> 
> I settled on putting it into libgomp.texi instead of
> a webpage or another location.
> 
> The 5.1 section should be fine – except for additional
> items. OpenMP 5.0 has stub wordings and needs to be filled.
> The version in the patch should be sufficient for now
> but it would be nice to have it completed before GCC 12.
> (Or even before the BoF in two weeks or OpenMP Con in
> a week, hmm.)
> 
> OK? Comments? Typo/wording fixes?
> 
> Tobias
> 
> PS: Besides the OpenMP implementation status, also:
> * implementation details/choices could be added.
> * some hints regarding tricks & tips related to OpenMP
>   and in particular offloading
>   (e.g. -foffload-options=-latomic might be needed for nvptx*)
> * user-friendlier documentation how to build the offload compiler.
>   (The offloading wiki page has too many internals and
>   lacks a step-by-step guide.)
> Not all should be in libgomp.texi, however.
> 
> (* Side note: it is mentioned indirectly: as example in
> https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload )
> 
> Currently, the OpenMP/offloading documentation is spread over:
> 
> * libgomp: https://gcc.gnu.org/onlinedocs/libgomp/
> * gcc: https://gcc.gnu.org/onlinedocs/gcc/
>   flags (-fopenmp(-simd), -foffload(-options=), ...)
> * gfortran: OpenMP + OpenMP Modules omp_lib and omp_lib_kinds
>   (and likewise for OpenACC) https://gcc.gnu.org/onlinedocs/gfortran/
> * Project page: https://gcc.gnu.org/projects/gomp/
> * Wiki page: https://gcc.gnu.org/wiki/openmp
>   (likewise: https://gcc.gnu.org/wiki/OpenACC
>   and also: https://gcc.gnu.org/wiki/OpenACC/Implementation%20Status )
> * Offloading: https://gcc.gnu.org/wiki/Offloading
>   plus https://gcc.gnu.org/wiki/nvptx
>   plus configure-time options at https://gcc.gnu.org/install/configure.html
> 
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

> libgomp.texi: Add OpenMP Implementation Status
> 
> libgomp/
> 	* libgomp.texi (Enabling OpenMP): Refer to OMP spec in general
> 	not to 4.5; link to new section.
> 	(OpenMP Implementation Status): New.

Ok.  I'll try to provide the 5.0 implementation status soon.

	Jakub

Re: [Patch] libgomp.texi: Add OpenMP Implementation Status

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

Hi Jakub,

On 07.09.21 10:14, Jakub Jelinek wrote:
> libgomp.texi: Add OpenMP Implementation Status
>> libgomp/
>>      * libgomp.texi (Enabling OpenMP): Refer to OMP spec in general
>>      not to 4.5; link to new section.
>>      (OpenMP Implementation Status): New.
> Ok.  I'll try to provide the 5.0 implementation status soon.

Attached is a first go for the 5.0 implementation status, just based on
Appendix B.

It cannot harm to proof read it – and extending it as follow up with
additional items and more details, implementation-specific behavior and
the like is useful and appreciated.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Attachment #2: omp-status-5.0.diff --]
[-- Type: text/x-patch, Size: 5155 bytes --]

libgomp.texi: Extend OpenMP 5.0 Implementation Status

libgomp/
        * libgomp.texi (OpenMP Implementation Status): Extend
	OpenMP 5.0 section.
        
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 0ae9c3260ff..e1bfb4839a9 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -172,8 +172,87 @@ The OpenMP 4.5 specification is fully supported.
 @node OpenMP 5.0
 @section OpenMP 5.0
 
-Partial support of the OpenMP 5.0 specification. The OMPT and the OMPD
-interfaces are unsupported.
+@unnumberedsubsec New features listed in Appendix B of the OpenMP specification
+@c This list is sorted as in OpenMP 5.1's B.3 not as in OpenMP 5.0's B.2
+
+@multitable @columnfractions .60 .10 .25
+@headitem Description @tab Status @tab Comments
+@item Array shaping @tab N @tab
+@item Array sections with non-unit strides in C and C++ @tab N @tab
+@item Iterators @tab Y @tab
+@item @code{metadirective} directive @tab N @tab
+@item @code{declare variant} directive @tab P @tab Only C and C++
+@item @emph{target-offload-var} ICV and @code{OMP_TARGET_OFFLOAD}
+      env variable @tab Y @tab
+@item Nested-parallel changes to @emph{max-active-levels-var} ICV @tab Y @tab
+@item @code{requires} directive @tab P
+      @tab Only fulfillable requirement is @code{atomic_default_mem_order}
+@item @code{teams} construct outside an enclosing target region @tab Y @tab
+@item Non-rectangular loop nests @tab Y @tab
+@item @code{!=} as relational-op in canonical loop form for C/C++ @tab Y @tab
+@item @code{nonmonotonic} as default loop schedule modifier for worksharing-loop
+      constructs @tab Y @tab
+@item Collapse of associated loops that are imperfectly nested loops @tab N @tab
+@item Clauses @code{if}, @code{nontemporal} and @code{order(concurrent)} in
+      @code{simd} construct @tab Y @tab
+@item @code{atomic} constructs in @code{simd} @tab Y @tab
+@item @code{loop} construct @tab Y @tab
+@item @code{order(concurrent)} clause @tab Y @tab
+@item @code{scan} directive and @code{in_scan} modifier for the
+      @code{reduction} clause @tab Y @tab
+@item @code{in_reduction} clause on @code{task} constructs @tab Y @tab
+@item @code{in_reduction} clause on @code{target} constructs @tab P
+      @tab Only C/C++, @code{nowait} only stub
+@item @code{task_reduction} clause with @code{taskgroup} @tab Y @tab
+@item @code{task} modifier to @code{reduction} clause @tab Y @tab
+@item @code{affinity} clause to @code{task} construct @tab Y @tab
+@item @code{detach} clause to @code{task} construct @tab Y @tab
+@item @code{omp_fulfill_event} runtime routine @tab Y @tab
+@item @code{reduction} and @code{in_reduction} clauses on @code{taskloop}
+      and @code{taskloop simd} constructs @tab Y @tab
+@item @code{taskloop} construct cancelable by @code{cancel} construct
+      @tab Y @tab
+@item @code{mutexinouset} @emph{dependence-type} for @code{depend} clause
+      @tab Y @tab
+@item Predefined memory spaces, memory allocators, allocator traits
+      @tab Y @tab Some are only stubs
+@item Memory management routines @tab Y @tab
+@item @code{allocate} directive @tab N @tab
+@item @code{allocate} clause @tab P @tab initial support in C/C++ only
+@item @code{use_device_addr} clause on @code{target data} @tab Y @tab
+@item @code{ancestor} modifier on @code{device} clause @tab P @tab Reverse offload unsupported
+@item Implicit declare target directive @tab Y @tab
+@item Discontiguous array section with @code{target update} construct
+      @tab N @tab
+@item C/C++'s lvalue expressions in @code{to}, @code{from}, @code{depend}
+      and @code{map} clause @tab Y @tab
+@item Nested @code{declare target} directive @tab Y @tab
+@item Combined @code{master} constructs @tab Y @tab
+@item @code{depend} clause on @code{taskwait} @tab Y @tab
+@item Weak memory ordering clauses on @code{atomic} and @code{flush} construct
+      @tab Y @tab
+@item @code{hint} clause on the @code{atomic} construct @tab Y @tab
+@item @code{depobj} construct and depend objects  @tab Y @tab
+@item Lock hints were renamed to synchronization hints @tab Y @tab
+@item @code{conditional} modifier to @code{lastprivate} clause @tab Y @tab
+@item Map-order clarifications @tab P @tab
+@item @code{close} @emph{map-type-modifier} @tab Y @tab
+@item Mapping C/C++ pointer variables and to assign the address of
+      device memory mapped by an array section @tab P @tab
+@item Mapping of Fortran pointer and allocatable variables, including pointer
+      and allocatable components of variables
+      @tab P @tab Mapping of vars with allocatable components unspported
+@item @code{defaultmap} extensions @tab Y @tab
+@item @code{declare mapper} directive @tab N @tab
+@item @code{omp_get_supported_active_levels} routine @tab Y @tab
+@item Runtime routines and environment variables to display runtime thread
+      affinity information @tab Y @tab
+@item @code{omp_pause_resource} and @code{omp_pause_resource_all} runtime routines
+      @tab Y @tab
+@item @code{omp_get_device_num} runtime routine @tab Y @tab
+@item OMPT interface @tab N @tab
+@item OMPD interface @tab N @tab
+@end multitable
 
 @node OpenMP 5.1
 @section OpenMP 5.1

Re: [Patch] libgomp.texi: Add OpenMP Implementation Status

[Jakub Jelinek]

On Tue, Sep 07, 2021 at 12:39:01PM +0200, Tobias Burnus wrote:
> +@item @code{declare variant} directive @tab P @tab Only C and C++

Even for C/C++, we don't handle the simd stuff there (where we should be
expecting a different function types in those cases, ones following the
declare simd ABIs).  So, essentially it is correct only on
non-x86/non-aarch64, because other arches don't have their declare simd
ABIs.

> +@item C/C++'s lvalue expressions in @code{to}, @code{from}, @code{depend}
> +      and @code{map} clause @tab Y @tab

I think this is not implemented yet, at least not in trunk.
We don't allow map(to:foo(234)[:32]) or map(to:bar()->x->y[5].z[3]) etc.

> +@item @code{close} @emph{map-type-modifier} @tab Y @tab

But it is stub only, though not sure if we in short term plan something
else.  So perhaps ok.

	Jakub

Re: [Patch] libgomp.texi: Add OpenMP Implementation Status

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On 07.09.21 12:49, Jakub Jelinek wrote:
> On Tue, Sep 07, 2021 at 12:39:01PM +0200, Tobias Burnus wrote:
>> +@item @code{declare variant} directive @tab P @tab Only C and C++
> Even for C/C++, we don't handle the simd stuff there (where we should be
> expecting a different function types in those cases, ones following the
> declare simd ABIs).  So, essentially it is correct only on
> non-x86/non-aarch64, because other arches don't have their declare simd
> ABIs.
I now use: ", simd taits not handled".
>> +@item C/C++'s lvalue expressions in @code{to}, @code{from}, @code{depend}
>> +      and @code{map} clause @tab Y @tab
> I think this is not implemented yet, at least not in trunk.
> We don't allow map(to:foo(234)[:32]) or map(to:bar()->x->y[5].z[3]) etc.

I somehow had the impression that I saw lvalues for 'depend', but while
they are more complicated, I think I did not see f()[1] etc. – For
mapping, I did see patches implementing stuff like 'z->x->y[5]' (which
are pending review) but I think that even those did not use a function
call on the left. Thus, a simple pilot error.

-> 'N'

>> +@item @code{close} @emph{map-type-modifier} @tab Y @tab
> But it is stub only, though not sure if we in short term plan something
> else.  So perhaps ok.

I have now added "Stub only" to both the 'close' modifier and, for
completeness, to the the 'affinity' clause. – I think both are
relatively boring; possibly, with unified shared memory or (for
affinity) real NUMA memory, they become a tad more useful.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Attachment #2: omp-status-5.0-v2.diff --]
[-- Type: text/x-patch, Size: 5204 bytes --]

libgomp.texi: Extend OpenMP 5.0 Implementation Status

libgomp/
        * libgomp.texi (OpenMP Implementation Status): Extend
	OpenMP 5.0 section.

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 0ae9c3260ff..fedc20b4abe 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -172,8 +172,89 @@ The OpenMP 4.5 specification is fully supported.
 @node OpenMP 5.0
 @section OpenMP 5.0
 
-Partial support of the OpenMP 5.0 specification. The OMPT and the OMPD
-interfaces are unsupported.
+@unnumberedsubsec New features listed in Appendix B of the OpenMP specification
+@c This list is sorted as in OpenMP 5.1's B.3 not as in OpenMP 5.0's B.2
+
+@multitable @columnfractions .60 .10 .25
+@headitem Description @tab Status @tab Comments
+@item Array shaping @tab N @tab
+@item Array sections with non-unit strides in C and C++ @tab N @tab
+@item Iterators @tab Y @tab
+@item @code{metadirective} directive @tab N @tab
+@item @code{declare variant} directive
+      @tab P @tab Only C and C++, simd taits not handled
+@item @emph{target-offload-var} ICV and @code{OMP_TARGET_OFFLOAD}
+      env variable @tab Y @tab
+@item Nested-parallel changes to @emph{max-active-levels-var} ICV @tab Y @tab
+@item @code{requires} directive @tab P
+      @tab Only fulfillable requirement is @code{atomic_default_mem_order}
+@item @code{teams} construct outside an enclosing target region @tab Y @tab
+@item Non-rectangular loop nests @tab Y @tab
+@item @code{!=} as relational-op in canonical loop form for C/C++ @tab Y @tab
+@item @code{nonmonotonic} as default loop schedule modifier for worksharing-loop
+      constructs @tab Y @tab
+@item Collapse of associated loops that are imperfectly nested loops @tab N @tab
+@item Clauses @code{if}, @code{nontemporal} and @code{order(concurrent)} in
+      @code{simd} construct @tab Y @tab
+@item @code{atomic} constructs in @code{simd} @tab Y @tab
+@item @code{loop} construct @tab Y @tab
+@item @code{order(concurrent)} clause @tab Y @tab
+@item @code{scan} directive and @code{in_scan} modifier for the
+      @code{reduction} clause @tab Y @tab
+@item @code{in_reduction} clause on @code{task} constructs @tab Y @tab
+@item @code{in_reduction} clause on @code{target} constructs @tab P
+      @tab Only C/C++, @code{nowait} only stub
+@item @code{task_reduction} clause with @code{taskgroup} @tab Y @tab
+@item @code{task} modifier to @code{reduction} clause @tab Y @tab
+@item @code{affinity} clause to @code{task} construct @tab Y @tab Stub only
+@item @code{detach} clause to @code{task} construct @tab Y @tab
+@item @code{omp_fulfill_event} runtime routine @tab Y @tab
+@item @code{reduction} and @code{in_reduction} clauses on @code{taskloop}
+      and @code{taskloop simd} constructs @tab Y @tab
+@item @code{taskloop} construct cancelable by @code{cancel} construct
+      @tab Y @tab
+@item @code{mutexinouset} @emph{dependence-type} for @code{depend} clause
+      @tab Y @tab
+@item Predefined memory spaces, memory allocators, allocator traits
+      @tab Y @tab Some are only stubs
+@item Memory management routines @tab Y @tab
+@item @code{allocate} directive @tab N @tab
+@item @code{allocate} clause @tab P @tab initial support in C/C++ only
+@item @code{use_device_addr} clause on @code{target data} @tab Y @tab
+@item @code{ancestor} modifier on @code{device} clause
+      @tab P @tab Reverse offload unsupported
+@item Implicit declare target directive @tab Y @tab
+@item Discontiguous array section with @code{target update} construct
+      @tab N @tab
+@item C/C++'s lvalue expressions in @code{to}, @code{from}, @code{depend}
+      and @code{map} clause @tab N @tab
+@item Nested @code{declare target} directive @tab Y @tab
+@item Combined @code{master} constructs @tab Y @tab
+@item @code{depend} clause on @code{taskwait} @tab Y @tab
+@item Weak memory ordering clauses on @code{atomic} and @code{flush} construct
+      @tab Y @tab
+@item @code{hint} clause on the @code{atomic} construct @tab Y @tab Stub only
+@item @code{depobj} construct and depend objects  @tab Y @tab
+@item Lock hints were renamed to synchronization hints @tab Y @tab
+@item @code{conditional} modifier to @code{lastprivate} clause @tab Y @tab
+@item Map-order clarifications @tab P @tab
+@item @code{close} @emph{map-type-modifier} @tab Y @tab
+@item Mapping C/C++ pointer variables and to assign the address of
+      device memory mapped by an array section @tab P @tab
+@item Mapping of Fortran pointer and allocatable variables, including pointer
+      and allocatable components of variables
+      @tab P @tab Mapping of vars with allocatable components unspported
+@item @code{defaultmap} extensions @tab Y @tab
+@item @code{declare mapper} directive @tab N @tab
+@item @code{omp_get_supported_active_levels} routine @tab Y @tab
+@item Runtime routines and environment variables to display runtime thread
+      affinity information @tab Y @tab
+@item @code{omp_pause_resource} and @code{omp_pause_resource_all} runtime
+      routines @tab Y @tab
+@item @code{omp_get_device_num} runtime routine @tab Y @tab
+@item OMPT interface @tab N @tab
+@item OMPD interface @tab N @tab
+@end multitable
 
 @node OpenMP 5.1
 @section OpenMP 5.1

Re: [Patch] libgomp.texi: Add OpenMP Implementation Status

[Jakub Jelinek]

On Tue, Sep 07, 2021 at 01:22:43PM +0200, Tobias Burnus wrote:
> On 07.09.21 12:49, Jakub Jelinek wrote:
> > On Tue, Sep 07, 2021 at 12:39:01PM +0200, Tobias Burnus wrote:
> > > +@item @code{declare variant} directive @tab P @tab Only C and C++
> > Even for C/C++, we don't handle the simd stuff there (where we should be
> > expecting a different function types in those cases, ones following the
> > declare simd ABIs).  So, essentially it is correct only on
> > non-x86/non-aarch64, because other arches don't have their declare simd
> > ABIs.
> I now use: ", simd taits not handled".

s/taits/traits/ and I'd add /handled/& correctly/

> > > +@item C/C++'s lvalue expressions in @code{to}, @code{from}, @code{depend}
> > > +      and @code{map} clause @tab Y @tab
> > I think this is not implemented yet, at least not in trunk.
> > We don't allow map(to:foo(234)[:32]) or map(to:bar()->x->y[5].z[3]) etc.
> 
> I somehow had the impression that I saw lvalues for 'depend', but while
> they are more complicated, I think I did not see f()[1] etc. – For
> mapping, I did see patches implementing stuff like 'z->x->y[5]' (which
> are pending review) but I think that even those did not use a function
> call on the left. Thus, a simple pilot error.

We do indeed support it for depend (and affinity), just don't support in
the lvalue case array sections, so perhaps split the
depend case from the other clauses.  The depend parsing tries to parse it
as the rigid varname followed by optional . field or array section and if
that fails, parses it as an expression, verifies it is lvalue and just
uses the address of that lvalue as the depend address.
While for map/to/from, I think what we need to do is make the OpenMP array
section a new tree code (perhaps C/C++ FE only), which is not recognized by
default, only when certain flag is set, set that flag while parsing
map/to/from/depend/affinity operands and clear afterwards, use normal
expression parsing and then verify after parsing that it is only used in the
spots where it can be used.

> I have now added "Stub only" to both the 'close' modifier and, for
> completeness, to the the 'affinity' clause. – I think both are
> relatively boring; possibly, with unified shared memory or (for
> affinity) real NUMA memory, they become a tad more useful.

True.

	Jakub

Re: [Patch] libgomp.texi: Add OpenMP Implementation Status

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

On 07.09.21 13:34, Jakub Jelinek wrote:
> On Tue, Sep 07, 2021 at 01:22:43PM +0200, Tobias Burnus wrote:
>> On 07.09.21 12:49, Jakub Jelinek wrote:
> s/taits/traits/ and I'd add /handled/& correctly/
fixed.
>>>> +@item C/C++'s lvalue expressions in @code{to}, @code{from}, @code{depend}
>>>> +      and @code{map} clause @tab Y @tab
>>> I think this is not implemented yet, at least not in trunk.
>>> We don't allow map(to:foo(234)[:32]) or map(to:bar()->x->y[5].z[3]) etc.
>> I somehow had the impression that I saw lvalues for 'depend', [...]
> We do indeed support it for depend (and affinity), just don't support in
> the lvalue case array sections, so perhaps split the
> depend case from the other clauses.  The depend parsing tries to parse it
> as the rigid varname followed by optional . field or array section and if
> that fails, parses it as an expression, verifies it is lvalue and just
> uses the address of that lvalue as the depend address.
Is this okay (Y) – or should be better improved (P + comment)? I did use
"Y".
> While for map/to/from, I think what we need to do is make the OpenMP array
> section a new tree code (perhaps C/C++ FE only), ...
Now split off and marked as "N".

I did look through some lists – and found range-based for loops (Y) as
item not in Appendix B. (And fixed one typo)

Anything else? Otherwise, maybe we should get this in – and then slowly
improve those lists...

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Attachment #2: omp-status-5.0-v3.diff --]
[-- Type: text/x-patch, Size: 6018 bytes --]

libgomp.texi: Extend OpenMP 5.0 Implementation Status

libgomp/
        * libgomp.texi (OpenMP Implementation Status): Extend
	OpenMP 5.0 section.
	(OpenACC Profiling Interface): Fix typo.

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 0ae9c3260ff..64085182620 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -172,8 +172,98 @@ The OpenMP 4.5 specification is fully supported.
 @node OpenMP 5.0
 @section OpenMP 5.0
 
-Partial support of the OpenMP 5.0 specification. The OMPT and the OMPD
-interfaces are unsupported.
+@unnumberedsubsec New features listed in Appendix B of the OpenMP specification
+@c This list is sorted as in OpenMP 5.1's B.3 not as in OpenMP 5.0's B.2
+
+@multitable @columnfractions .60 .10 .25
+@headitem Description @tab Status @tab Comments
+@item Array shaping @tab N @tab
+@item Array sections with non-unit strides in C and C++ @tab N @tab
+@item Iterators @tab Y @tab
+@item @code{metadirective} directive @tab N @tab
+@item @code{declare variant} directive
+      @tab P @tab Only C and C++, simd traits not handled correctly
+@item @emph{target-offload-var} ICV and @code{OMP_TARGET_OFFLOAD}
+      env variable @tab Y @tab
+@item Nested-parallel changes to @emph{max-active-levels-var} ICV @tab Y @tab
+@item @code{requires} directive @tab P
+      @tab Only fulfillable requirement is @code{atomic_default_mem_order}
+@item @code{teams} construct outside an enclosing target region @tab Y @tab
+@item Non-rectangular loop nests @tab Y @tab
+@item @code{!=} as relational-op in canonical loop form for C/C++ @tab Y @tab
+@item @code{nonmonotonic} as default loop schedule modifier for worksharing-loop
+      constructs @tab Y @tab
+@item Collapse of associated loops that are imperfectly nested loops @tab N @tab
+@item Clauses @code{if}, @code{nontemporal} and @code{order(concurrent)} in
+      @code{simd} construct @tab Y @tab
+@item @code{atomic} constructs in @code{simd} @tab Y @tab
+@item @code{loop} construct @tab Y @tab
+@item @code{order(concurrent)} clause @tab Y @tab
+@item @code{scan} directive and @code{in_scan} modifier for the
+      @code{reduction} clause @tab Y @tab
+@item @code{in_reduction} clause on @code{task} constructs @tab Y @tab
+@item @code{in_reduction} clause on @code{target} constructs @tab P
+      @tab Only C/C++, @code{nowait} only stub
+@item @code{task_reduction} clause with @code{taskgroup} @tab Y @tab
+@item @code{task} modifier to @code{reduction} clause @tab Y @tab
+@item @code{affinity} clause to @code{task} construct @tab Y @tab Stub only
+@item @code{detach} clause to @code{task} construct @tab Y @tab
+@item @code{omp_fulfill_event} runtime routine @tab Y @tab
+@item @code{reduction} and @code{in_reduction} clauses on @code{taskloop}
+      and @code{taskloop simd} constructs @tab Y @tab
+@item @code{taskloop} construct cancelable by @code{cancel} construct
+      @tab Y @tab
+@item @code{mutexinouset} @emph{dependence-type} for @code{depend} clause
+      @tab Y @tab
+@item Predefined memory spaces, memory allocators, allocator traits
+      @tab Y @tab Some are only stubs
+@item Memory management routines @tab Y @tab
+@item @code{allocate} directive @tab N @tab
+@item @code{allocate} clause @tab P @tab initial support in C/C++ only
+@item @code{use_device_addr} clause on @code{target data} @tab Y @tab
+@item @code{ancestor} modifier on @code{device} clause
+      @tab P @tab Reverse offload unsupported
+@item Implicit declare target directive @tab Y @tab
+@item Discontiguous array section with @code{target update} construct
+      @tab N @tab
+@item C/C++'s lvalue expressions in @code{to}, @code{from}
+      and @code{map} clauses @tab N @tab
+@item C/C++'s lvalue expressions in @code{depend} clauses @tab Y @tab
+@item Nested @code{declare target} directive @tab Y @tab
+@item Combined @code{master} constructs @tab Y @tab
+@item @code{depend} clause on @code{taskwait} @tab Y @tab
+@item Weak memory ordering clauses on @code{atomic} and @code{flush} construct
+      @tab Y @tab
+@item @code{hint} clause on the @code{atomic} construct @tab Y @tab Stub only
+@item @code{depobj} construct and depend objects  @tab Y @tab
+@item Lock hints were renamed to synchronization hints @tab Y @tab
+@item @code{conditional} modifier to @code{lastprivate} clause @tab Y @tab
+@item Map-order clarifications @tab P @tab
+@item @code{close} @emph{map-type-modifier} @tab Y @tab
+@item Mapping C/C++ pointer variables and to assign the address of
+      device memory mapped by an array section @tab P @tab
+@item Mapping of Fortran pointer and allocatable variables, including pointer
+      and allocatable components of variables
+      @tab P @tab Mapping of vars with allocatable components unspported
+@item @code{defaultmap} extensions @tab Y @tab
+@item @code{declare mapper} directive @tab N @tab
+@item @code{omp_get_supported_active_levels} routine @tab Y @tab
+@item Runtime routines and environment variables to display runtime thread
+      affinity information @tab Y @tab
+@item @code{omp_pause_resource} and @code{omp_pause_resource_all} runtime
+      routines @tab Y @tab
+@item @code{omp_get_device_num} runtime routine @tab Y @tab
+@item OMPT interface @tab N @tab
+@item OMPD interface @tab N @tab
+@end multitable
+
+@unnumberedsubsec Other new OpenMP 5.0 features
+
+@multitable @columnfractions .60 .10 .25
+@headitem Description @tab Status @tab Comments
+@item Supporting C++'s range-based for loop @tab Y @tab
+@end multitable
+
 
 @node OpenMP 5.1
 @section OpenMP 5.1
@@ -3853,7 +3943,7 @@ Remarks about certain event types:
 @c See 'DEVICE_INIT_INSIDE_COMPUTE_CONSTRUCT' in
 @c 'libgomp.oacc-c-c++-common/acc_prof-kernels-1.c',
 @c 'libgomp.oacc-c-c++-common/acc_prof-parallel-1.c'.
-Whan a compute construct triggers implicit
+When a compute construct triggers implicit
 @code{acc_ev_device_init_start} and @code{acc_ev_device_init_end}
 events, they currently aren't @emph{nested within} the corresponding
 @code{acc_ev_compute_construct_start} and

Re: [Patch] libgomp.texi: Add OpenMP Implementation Status

[Jakub Jelinek]

On Tue, Sep 07, 2021 at 06:07:35PM +0200, Tobias Burnus wrote:
> > depend case from the other clauses.  The depend parsing tries to parse it
> > as the rigid varname followed by optional . field or array section and if
> > that fails, parses it as an expression, verifies it is lvalue and just
> > uses the address of that lvalue as the depend address.
> Is this okay (Y) – or should be better improved (P + comment)? I did use
> "Y".

Let's go with Y.

> > While for map/to/from, I think what we need to do is make the OpenMP array
> > section a new tree code (perhaps C/C++ FE only), ...
> Now split off and marked as "N".
> 
> I did look through some lists – and found range-based for loops (Y) as
> item not in Appendix B. (And fixed one typo)

Bronis didn't want that bullet because there was C++11/C++14 support bullet
and he argued that range based for loops falls into that.
But IMHO range for is significant change that is worth explicit bullet.

> libgomp.texi: Extend OpenMP 5.0 Implementation Status
> 
> libgomp/
>         * libgomp.texi (OpenMP Implementation Status): Extend
> 	OpenMP 5.0 section.
> 	(OpenACC Profiling Interface): Fix typo.

Ok, thanks.

	Jakub