Re: [patch] libgomp.texi: Update "Enabling OpenMP"
On Sat, Oct 14, 2023 at 11:57:39PM +0200, Jakub Jelinek wrote:
> On Sat, Oct 14, 2023 at 03:46:52PM -0600, Sandra Loosemore wrote:
> > On 10/14/23 13:43, Tobias Burnus wrote:
> > > When browsing libgomp doc, I came across
> > > https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html>> First, I
> > > found especially the Fortran part difficult to read. Secondly,
> > > it missed the C++ attribute syntax. And I also missed a reference to
> > > -fopenmp-simd.
> > >
> > > The attached patch tries to improve this. Note that it talks about C and
> > > C++ attributes, even though C23's [[omp::]] support has not yet landed.
> > > (But is expected very soon.)
> >
> > Is somebody actively working on implementing that, and expecting to get it
> > in before Stage 1 closes? I don't think we should document features that
>
> I am (attached is a WIP, which can now compile most of g++.dg/gomp/attrs-1.C
> in -std=c2x -fopenmp, except for the scan/section directives).
> That said, I agree it might be premature to document it before it is in.
Here is an updated WIP patch.
It handles everything except diagnostics of mixing attribute and pragma
syntax on begin assumes/end assumes (for now xfailed in attrs-15.c) and
omp::decl support is commented out.
--- gcc/cp/parser.h.jj 2023-10-13 18:34:03.335431229 +0200
+++ gcc/cp/parser.h 2023-10-16 17:48:49.804081420 +0200
@@ -408,7 +408,8 @@ struct GTY(()) cp_parser {
identifiers) rather than an explicit template parameter list. */
bool fully_implicit_function_template_p;
- /* TRUE if omp::directive or omp::sequence attributes may not appear. */
+ /* TRUE if omp::directive, omp::decl or omp::sequence attributes may not
+ appear. */
bool omp_attrs_forbidden_p;
/* Tracks the function's template parameter list when declaring a function
--- gcc/cp/parser.cc.jj 2023-10-16 17:25:32.433781786 +0200
+++ gcc/cp/parser.cc2023-10-16 17:48:49.783081715 +0200
@@ -43837,7 +43837,8 @@ cp_parser_omp_section_scan (cp_parser *p
{
tree first = cp_lexer_peek_nth_token (parser->lexer, i)->u.value;
tree second = cp_lexer_peek_nth_token (parser->lexer, i + 2)->u.value;
- if (strcmp (IDENTIFIER_POINTER (first), "directive"))
+ if (strcmp (IDENTIFIER_POINTER (first), "directive")
+ && strcmp (IDENTIFIER_POINTER (first), "__directive__"))
continue;
if (strcmp (IDENTIFIER_POINTER (second), directive) == 0)
break;
--- gcc/testsuite/g++.dg/gomp/attrs-2.C.jj 2022-09-27 08:22:37.129634552
+0200
+++ gcc/testsuite/g++.dg/gomp/attrs-2.C 2023-10-17 18:02:13.512329537 +0200
@@ -1,4 +1,4 @@
-// { dg-do compile { target c++17 } }
+// { dg-do compile { target c++11 } }
typedef enum omp_allocator_handle_t
: __UINTPTR_TYPE__
@@ -162,7 +162,11 @@ bar (int d, int m, int i1, int i2, int i
private (p),firstprivate (f),if (parallel:
i2),default(shared),shared(s),copyin(t),reduction(+:r),num_threads
(nth),proc_bind(spread),
lastprivate (l),allocate (f))]]
{
+#if __cplusplus >= 201703L
[[using omp:directive (section)]]
+#else
+[[omp::directive (section)]]
+#endif
{}
[[omp::sequence (omp::directive (section))]]
{}
@@ -176,11 +180,20 @@ bar (int d, int m, int i1, int i2, int i
{}
}
[[omp::directive (barrier)]];
+#if __cplusplus >= 201703L
[[using omp:sequence (omp::directive (single, private (p),firstprivate
(f),allocate (f),nowait))]]
+#else
+ [[omp::sequence (omp::directive (single, private (p),firstprivate
(f),allocate (f),nowait))]]
+#endif
;
[[omp::sequence (directive (barrier))]];
+#if __cplusplus >= 201703L
[[using omp:sequence (directive (parallel, private (p)),
omp::directive (single, copyprivate (p),firstprivate (f),allocate (f)))]]
+#else
+ [[omp::sequence (directive (parallel, private (p)),
+omp::directive (single, copyprivate (p),firstprivate (f),allocate (f)))]]
+#endif
p = 6;
[[omp::directive (target parallel,
device(d),map (tofrom: m),if (target: i1),private (p),firstprivate
(f),defaultmap(tofrom: scalar),is_device_ptr (idp),
@@ -194,7 +207,13 @@ bar (int d, int m, int i1, int i2, int i
allocate (omp_default_mem_alloc:f),in_reduction(+:r2),has_device_addr
(hda))]]
for (int i = 0; i < 64; i++)
ll++;
- [[using omp:directive (target parallel for,
+ [[
+#if __cplusplus >= 201703L
+using omp:
+#else
+omp::
+#endif
+directive (target parallel for,
device(d),map (tofrom: m),if (target: i1),private (p),firstprivate
(f),defaultmap(tofrom: scalar),is_device_ptr (idp),
if (parallel: i2),default(shared),shared(s),reduction(+:r),num_threads
(nth),proc_bind(spread),
lastprivate (l),linear (ll:1),schedule(static, 4),collapse(1),nowait
depend(inout: dd[0]),order(concurrent),
@@ -209,12 +228,24 @@ bar (int d, int m, int i1, int i2, int i
allocate (omp_default_mem_alloc:f),in_reduction(+:r2),has_device_addr
(hda)))]]
for (int i = 0; i < 64; i++)
ll++;
-
Re: [patch] libgomp.texi: Update "Enabling OpenMP" + OpenACC / invoke.texi: -fopenacc/-fopenmp update (was: Re: [patch] libgomp.texi: Update "Enabling OpenMP")
On 10/15/23 04:42, Tobias Burnus wrote: Updated patch attached. This version looks OK to me. -Sandra
[patch] libgomp.texi: Update "Enabling OpenMP" + OpenACC / invoke.texi: -fopenacc/-fopenmp update (was: Re: [patch] libgomp.texi: Update "Enabling OpenMP")
Hi Sandra and Jakub,
I have now updated the patch; on the way, I found an issue in -fopenacc ('!$' is
not OpenACC and no longer supported) and the same @code/@samp.
I also updated invoke.texi for the same @code/@samp - and added both '!$'
and mentioned the 'c$'/'*$' Fortran fixed-form variant. I think the most
important bit is that '!$' is also supported by -fopenmp-simd as that's not
covered by the OpenMP specification.
Otherwise:
On 14.10.23 23:46, Sandra Loosemore wrote:
On 10/14/23 13:43, Tobias Burnus wrote:
The attached patch tries to improve this. Note that it talks about C and
C++ attributes, even though C23's [[omp::]] support has not yet landed.
(But is expected very soon.)
Is somebody actively working on implementing that, and expecting to
get it in before Stage 1 closes? I don't think we should document
features that don't exist yet.
Yes. But I have now sneaked in an 'in C++' which can also be easily
removed once Jakub's patch is committed or as part of Jakub's patch.
This syntax for C also isn't even in the draft OpenMP 6.0 document so
at this point
Well, it is in the git version, which will be released as TR12 in about
a month (in time for SC23). It is very unlikely to get removed before
OpenMP 6.0 as it is an obvious extension to C++11's attribute support,
now that C supports attributes as well.
Other than that...
Use @option markup on options, not @command.
Fixed. Was preexisting and I copied it once. I've now checked, the only
other use in libgomp.texi was for an actual command (nvprof).
And I think all those @code markups should be @samp instead, or you
could just replace this whole blurb with something like "This flag
enables recognition of the directive syntax documented in the OpenMP
specification, and also arranges for automatic linking..."
I think it is more user friendly to document the sentinels. However, I
concur that @samp is better.
+OpenMP directives, which do not require the linking of neither the
s/, which/ that/
I have now used it, but I think it sound odd:
"enables *a* subset of OpenMP directives *that* do not require the linking"
I concur that with "*the* subset ... *that*" makes sense but I want to
avoid stating that *all* directives that do not require linking of
libgomp/libpthread are supported.
invoke.texi lists all supported directives, but I am not really fond of
repeating that list.
s/neither/either/
The fun of whether double negation cancels or enforces the negation or
.. ("not .. neither / nor").
Cf. https://en.wikipedia.org/wiki/Double_negative
In German and English, both cancellation and enforcement seem to be
possible, the latter especially with dialects - while the standard
language tends to avoid double negation.
Updated patch attached.
Thanks,
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
libgomp.texi: Update "Enabling OpenMP" + OpenACC / invoke.texi: -fopenacc/-fopenmp update
The OpenACC specification does not mention the '!$ ' sentinel for conditional
compilation and the feature was removed in r11-5572-g1d6f6ac693a860
for PR fortran/98011.
libgomp/
* libgomp.texi (Enabling OpenMP): Update for C/C++ attributes;
improve wording especially for Fortran; mention -fopenmp-simd.
(Enabling OpenACC): Minor cleanup; remove conditional compilation
sentinel.
gcc/
* doc/invoke.texi (-fopenacc, -fopenmp, -fopenmp-simd): Use @samp not
@code; document more completely the supported Fortran sentinels.
gcc/fortran
* scanner.cc (skip_free_comments, skip_fixed_comments): Remove
leftover 'OpenACC' from comments about OpenMP's conditional
compilation sentinel.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index fee659462ff..eb714d18511 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2748,9 +2748,10 @@ Typical command lines are
@opindex fopenacc
@cindex OpenACC accelerator programming
@item -fopenacc
-Enable handling of OpenACC directives @code{#pragma acc} in C/C++ and
-@code{!$acc} in Fortran. When @option{-fopenacc} is specified, the
-compiler generates accelerated code according to the OpenACC Application
+Enable handling of OpenACC directives @samp{#pragma acc} in C/C++ and
+@samp{!$acc} in free-form Fortran and @samp{!$acc}, @samp{c$acc} and
+@samp{*$acc} in fixed-form Fortran. When @option{-fopenacc} is specified,
+the compiler generates accelerated code according to the OpenACC Application
Programming Interface v2.6 @w{@uref{https://www.openacc.org}}. This option
implies @option{-pthread}, and thus is only supported on targets that
have support for @option{-pthread}.
@@ -2766,10 +2767,12 @@ can be omitted, to use a target-specific default value.
@opindex fopenmp
@cindex OpenMP parallel
@item -fopenmp
-Enable handling of OpenMP directives @code{#pragma omp} in
Re: [patch] libgomp.texi: Update "Enabling OpenMP"
On Sat, Oct 14, 2023 at 03:46:52PM -0600, Sandra Loosemore wrote:
> On 10/14/23 13:43, Tobias Burnus wrote:
> > When browsing libgomp doc, I came across
> > https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html>> First, I
> > found especially the Fortran part difficult to read. Secondly,
> > it missed the C++ attribute syntax. And I also missed a reference to
> > -fopenmp-simd.
> >
> > The attached patch tries to improve this. Note that it talks about C and
> > C++ attributes, even though C23's [[omp::]] support has not yet landed.
> > (But is expected very soon.)
>
> Is somebody actively working on implementing that, and expecting to get it
> in before Stage 1 closes? I don't think we should document features that
I am (attached is a WIP, which can now compile most of g++.dg/gomp/attrs-1.C
in -std=c2x -fopenmp, except for the scan/section directives).
That said, I agree it might be premature to document it before it is in.
> don't exist yet. This syntax for C also isn't even in the draft OpenMP 6.0
> document so at this point it's just a hypothetical extension.
It is in OpenMP spec git and it is very unlikely it would be removed.
Jakub
--- gcc/cp/parser.h.jj 2023-09-20 08:42:51.987008923 +0200
+++ gcc/cp/parser.h 2023-10-12 13:32:42.503496571 +0200
@@ -408,7 +408,8 @@ struct GTY(()) cp_parser {
identifiers) rather than an explicit template parameter list. */
bool fully_implicit_function_template_p;
- /* TRUE if omp::directive or omp::sequence attributes may not appear. */
+ /* TRUE if omp::directive, omp::decl or omp::sequence attributes may not
+ appear. */
bool omp_attrs_forbidden_p;
/* Tracks the function's template parameter list when declaring a function
--- gcc/c/c-decl.cc.jj 2023-10-11 10:59:12.378170030 +0200
+++ gcc/c/c-decl.cc 2023-10-11 17:23:42.902257966 +0200
@@ -61,6 +61,7 @@ along with GCC; see the file COPYING3.
#include "context.h" /* For 'g'. */
#include "omp-general.h"
#include "omp-offload.h" /* For offload_vars. */
+#include "c-parser.h"
#include "tree-pretty-print.h"
@@ -325,15 +326,34 @@ i_label_binding (tree node)
/* The resulting tree type. */
-union GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"),
+union GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE + 2 * (TREE_CODE
(&%h.generic) == C_TOKEN_VEC)"),
chain_next ("(union lang_tree_node *) c_tree_chain_next
(&%h.generic)"))) lang_tree_node
{
union tree_node GTY ((tag ("0"),
desc ("tree_node_structure (&%h)")))
generic;
struct lang_identifier GTY ((tag ("1"))) identifier;
+ struct c_tree_token_vec GTY ((tag ("2"))) c_token_vec;
};
+/* Langhook for tree_size. */
+size_t
+c_tree_size (enum tree_code code)
+{
+ gcc_checking_assert (code >= NUM_TREE_CODES);
+ switch (code)
+{
+case C_TOKEN_VEC: return sizeof (c_tree_token_vec);
+default:
+ switch (TREE_CODE_CLASS (code))
+ {
+ case tcc_declaration: return sizeof (tree_decl_non_common);
+ case tcc_type: return sizeof (tree_type_non_common);
+ default: gcc_unreachable ();
+ }
+}
+}
+
/* Track bindings and other things that matter for goto warnings. For
efficiency, we do not gather all the decls at the point of
definition. Instead, we point into the bindings structure. As
--- gcc/c/c-parser.cc.jj2023-10-11 10:59:12.426169364 +0200
+++ gcc/c/c-parser.cc 2023-10-13 17:47:27.32902 +0200
@@ -247,12 +247,21 @@ struct GTY(()) c_parser {
macro. */
BOOL_BITFIELD seen_string_literal : 1;
+ /* TRUE if omp::directive, omp::decl or omp::sequence attributes may not
+ appear. */
+ BOOL_BITFIELD omp_attrs_forbidden_p : 1;
+
/* Location of the last consumed token. */
location_t last_token_location;
/* Holds state for parsing collapsed OMP_FOR loops. Managed by
c_parser_omp_for_loop. */
struct omp_for_parse_data * GTY((skip)) omp_for_parse_state;
+
+ /* If we're in the context of OpenMP directives written as C23
+ attributes turned into pragma, vector of tokens created from that,
+ otherwise NULL. */
+ vec *in_omp_attribute_pragma;
};
/* Return a pointer to the Nth token in PARSERs tokens_buf. */
@@ -1383,6 +1392,17 @@ c_parser_skip_to_pragma_eol (c_parser *p
}
while (token_type != CPP_PRAGMA_EOL);
+ if (parser->in_omp_attribute_pragma)
+{
+ c_token *token = c_parser_peek_token (parser);
+ if (token->type == CPP_EOF)
+ {
+ parser->tokens = >tokens_buf[0];
+ parser->tokens_avail = token->flags;
+ parser->in_omp_attribute_pragma = NULL;
+ }
+}
+
parser->error = false;
}
@@ -5430,6 +5450,109 @@ c_parser_balanced_token_sequence (c_pars
}
}
+static bool c_parser_check_balanced_raw_token_sequence (c_parser *,
+ unsigned int *);
+
+/* Parse arguments of omp::directive or omp::decl attribute.
+
+
Re: [patch] libgomp.texi: Update "Enabling OpenMP"
On 10/14/23 13:43, Tobias Burnus wrote:
When browsing libgomp doc, I came across
https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html>>
First, I found especially the Fortran part difficult to read. Secondly,
it missed the C++ attribute syntax. And I also missed a reference to
-fopenmp-simd.
The attached patch tries to improve this. Note that it talks about C and
C++ attributes, even though C23's [[omp::]] support has not yet landed.
(But is expected very soon.)
Is somebody actively working on implementing that, and expecting to get it in
before Stage 1 closes? I don't think we should document features that don't
exist yet. This syntax for C also isn't even in the draft OpenMP 6.0 document
so at this point it's just a hypothetical extension. To me it seems a better
use of resources to finish implementing things that are actually in earlier
versions of the OpenMP standard, and to fill in documentation for features that
are actually implemented.
Other than that...
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 526d1be2955..d8126f96fe4 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -136,15 +136,22 @@ changed to GNU Offloading and Multi Processing Runtime
Library.
@node Enabling OpenMP
@chapter Enabling OpenMP
-To activate the OpenMP extensions for C/C++ and Fortran, the compile-time
-flag @command{-fopenmp} must be specified. This enables the OpenMP directive
-@code{#pragma omp} in C/C++ and @code{!$omp} directives in free form,
-@code{c$omp}, @code{*$omp} and @code{!$omp} directives in fixed form,
-@code{!$} conditional compilation sentinels in free form and @code{c$},
-@code{*$} and @code{!$} sentinels in fixed form, for Fortran. The flag also
-arranges for automatic linking of the OpenMP runtime library
+To activate the OpenMP extensions for C/C++ and Fortran, the compile-time
+flag @command{-fopenmp} must be specified. For C and C++, this enables
Use @option markup on options, not @command.
+the handling of the OpenMP directives using @code{#pragma omp} and the
+@code{[[omp::directive(...)]]}, @code{[[omp::sequence(...)]]} and
+@code{[[omp::decl(...)]]} attributes. For Fortran, it enables for
+free source form the @code{!$omp} sentinel for directives and the
+@code{!$} conditional compilation sentinel and for fixed source form the
+@code{c$omp}, @code{*$omp} and @code{!$omp} sentinels for directives and
+the @code{c$}, @code{*$} and @code{!$} conditional compilation sentinels.
+The flag also arranges for automatic linking of the OpenMP runtime library
(@ref{Runtime Library Routines}).
And I think all those @code markups should be @samp instead, or you could just
replace this whole blurb with something like "This flag enables recognition of
the directive syntax documented in the OpenMP specification, and also arranges
for automatic linking..."
+The @command{-fopenmp-simd} flag can be used to enable a subset of
This should be @option too.
+OpenMP directives, which do not require the linking of neither the
s/, which/ that/
s/neither/either/
+OpenMP runtime library nor the POSIX threads library.
+
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}.
-Sandra
[patch] libgomp.texi: Update "Enabling OpenMP"
When browsing libgomp doc, I came across
https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html
First, I found especially the Fortran part difficult to read. Secondly,
it missed the C++ attribute syntax. And I also missed a reference to
-fopenmp-simd.
The attached patch tries to improve this. Note that it talks about C and
C++ attributes, even though C23's [[omp::]] support has not yet landed.
(But is expected very soon.)
I also do not try to list what -fopenmp-simd supports as that's at
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-fopenmp
and I bet we won't keep both in sync and "man gcc" is more likely to be
up to date.
Comments?
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
libgomp.texi: Update "Enabling OpenMP"
libgomp/
* libgomp.texi (Enabling OpenMP): Update for C/C++ attributes;
improve wording especially for Fortran; mention -fopenmp-simd.
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 526d1be2955..d8126f96fe4 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -136,15 +136,22 @@ changed to GNU Offloading and Multi Processing Runtime Library.
@node Enabling OpenMP
@chapter Enabling OpenMP
-To activate the OpenMP extensions for C/C++ and Fortran, the compile-time
-flag @command{-fopenmp} must be specified. This enables the OpenMP directive
-@code{#pragma omp} in C/C++ and @code{!$omp} directives in free form,
-@code{c$omp}, @code{*$omp} and @code{!$omp} directives in fixed form,
-@code{!$} conditional compilation sentinels in free form and @code{c$},
-@code{*$} and @code{!$} sentinels in fixed form, for Fortran. The flag also
-arranges for automatic linking of the OpenMP runtime library
+To activate the OpenMP extensions for C/C++ and Fortran, the compile-time
+flag @command{-fopenmp} must be specified. For C and C++, this enables
+the handling of the OpenMP directives using @code{#pragma omp} and the
+@code{[[omp::directive(...)]]}, @code{[[omp::sequence(...)]]} and
+@code{[[omp::decl(...)]]} attributes. For Fortran, it enables for
+free source form the @code{!$omp} sentinel for directives and the
+@code{!$} conditional compilation sentinel and for fixed source form the
+@code{c$omp}, @code{*$omp} and @code{!$omp} sentinels for directives and
+the @code{c$}, @code{*$} and @code{!$} conditional compilation sentinels.
+The flag also arranges for automatic linking of the OpenMP runtime library
(@ref{Runtime Library Routines}).
+The @command{-fopenmp-simd} flag can be used to enable a subset of
+OpenMP directives, which do not require the linking of neither the
+OpenMP runtime library nor the POSIX threads library.
+
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}.
