| Message ID | cd19fd50-d488-beb7-132a-91b7c454ba2d@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
| Series | libgomp.texi: Add OpenMP Implementation Status | expand |
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
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
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
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
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
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
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
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 ---------------------------------------------------------------------