Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)
On Mon, Sep 11, 2023 at 03:21:54PM +0200, Tobias Burnus wrote:
> + if (TREE_STATIC (var))
> + {
> + if (allocator == NULL_TREE && allocator_loc == UNKNOWN_LOCATION)
> + error_at (loc, "% clause required for "
> +"static variable %qD", var);
> + else if (allocator
> +&& (tree_int_cst_sgn (allocator) != 1
> +|| tree_to_shwi (allocator) > 8))
Has anything checked that in this case allocator is actually INTEGER_CST
which fits into shwi? Otherwise tree_to_shwi will ICE.
Consider say allocator argument of
329857234985743598347598437598347594835743895743wb
or (((unsigned __int128) 0x123456789abcdef0) << 64)
Either tree_fits_shwi_p (allocator) check would do it, or perhaps
else if (allocator
&& TREE_CODE (allocator) == INTEGER_CST
&& wi::to_widest (allocator) > 0
&& wi::to_widest (allocator) <= 8)
?
> + if (allocator
> + && TREE_CODE (allocator) == VAR_DECL
> + && c_check_in_current_scope (var))
> + {
> + if (linemap_location_before_p (line_table, DECL_SOURCE_LOCATION (var),
> + DECL_SOURCE_LOCATION (allocator)))
> + {
> + error_at (OMP_CLAUSE_LOCATION (nl),
> + "allocator variable %qD must be declared before %qD",
> + allocator, var);
> + inform (DECL_SOURCE_LOCATION (allocator),
> + "allocator declared here");
> + inform (DECL_SOURCE_LOCATION (var), "declared here");
> + }
> + else
> +{
> + gcc_assert (cur_stmt_list
> + && TREE_CODE (cur_stmt_list) == STATEMENT_LIST);
> + tree_stmt_iterator l = tsi_last (cur_stmt_list);
> + while (!tsi_end_p (l))
> +{
> + if (linemap_location_before_p (line_table, EXPR_LOCATION (*l),
> + DECL_SOURCE_LOCATION (var)))
> +break;
> + if (TREE_CODE (*l) == MODIFY_EXPR
> + && TREE_OPERAND (*l, 0) == allocator)
> +{
> + error_at (EXPR_LOCATION (*l),
> +"allocator variable %qD, used in the "
> +"% directive for %qD, must not be "
> +"modified between declaration of %qD and its "
> +"% directive",
> +allocator, var, var);
> + inform (DECL_SOURCE_LOCATION (var), "declared here");
> + inform (OMP_CLAUSE_LOCATION (nl), "used here");
> + break;
> + }
> + --l;
> + }
> +}
BTW, it doesn't necessarily have to be just the simple case which you catch
here, namely that allocator is a VAR_DECL defined after var in current
scope.
One can have an expression which uses those other vars, say
int v;
int a = 1;
int b[n]; // VLA
b[a] = 5;
#pragma omp allocate (v) allocator (foo (a, [a]))
where foo would be some function which returns omp_allocator_handle_t.
Or it could be e.g. lambda declared later, etc.
I bet we can't catch everything, but perhaps e.g. doing the first
diagnostics from within walk_tree might be better.
Jakub
Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)
Hi,
thanks for the comments and for the line-number thing. (I wanted to
re-check it myself but then totally forgot about it.)
Attached is the updated patch, fixing the line-number comparison, the
C++ addition to the enum decl in two of the testcases, and adding
"allocator" to the one inform (both to the code and to one testcase).
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
OpenMP (C only): omp allocate - extend parsing support, improve diagnostic
The 'allocate' directive can be used for both stack and static variables.
While the parser in C and C++ was pre-existing, it missed several
diagnostics, which this commit adds - for now only for C.
While the "sorry, unimplemented" for static variables is still issues
during parsing, the sorry for stack variables is now issued in the
middle end, preparing for the actual implementation. (Again: only for C.)
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_construct): Move call to
c_parser_omp_allocate to ...
(c_parser_pragma): ... here.
(c_parser_omp_allocate): Avoid ICE is allocator could not be
parsed; set 'omp allocate' attribute for stack/automatic variables
and only reject static variables; add several additional
restriction checks.
* c-tree.h (c_mark_decl_jump_unsafe_in_current_scope): New prototype.
* c-decl.cc (decl_jump_unsafe): Return true for omp-allocated decls.
(c_mark_decl_jump_unsafe_in_current_scope): New.
(warn_about_goto, c_check_switch_jump_warnings): Add error for
omp-allocated decls.
gcc/ChangeLog:
* gimplify.cc (gimplify_bind_expr): Check for
insertion after variable cleanup. Convert 'omp allocate'
var-decl attribute to GOMP_alloc/GOMP_free calls.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/allocate-5.c: Fix testcase; make some
dg-messages for 'sorry' as c++, only.
* c-c++-common/gomp/directive-1.c: Make a 'sorry' c++ only.
* c-c++-common/gomp/allocate-9.c: New test.
* c-c++-common/gomp/allocate-11.c: New test.
* c-c++-common/gomp/allocate-12.c: New test.
* c-c++-common/gomp/allocate-14.c: New test.
* c-c++-common/gomp/allocate-15.c: New test.
gcc/c/c-decl.cc | 26 ++
gcc/c/c-parser.cc | 115 +++---
gcc/c/c-tree.h| 1 +
gcc/gimplify.cc | 40 +
gcc/testsuite/c-c++-common/gomp/allocate-11.c | 40 +
gcc/testsuite/c-c++-common/gomp/allocate-12.c | 49 +++
gcc/testsuite/c-c++-common/gomp/allocate-14.c | 26 ++
gcc/testsuite/c-c++-common/gomp/allocate-15.c | 28 +++
gcc/testsuite/c-c++-common/gomp/allocate-5.c | 60 +++---
gcc/testsuite/c-c++-common/gomp/allocate-9.c | 99 ++
gcc/testsuite/c-c++-common/gomp/directive-1.c | 2 +-
11 files changed, 444 insertions(+), 42 deletions(-)
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 649c5ae66c2..5822faf01b4 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -681,6 +681,11 @@ decl_jump_unsafe (tree decl)
if (VAR_P (decl) && C_DECL_COMPOUND_LITERAL_P (decl))
return false;
+ if (flag_openmp
+ && VAR_P (decl)
+ && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
+return true;
+
/* Always warn about crossing variably modified types. */
if ((VAR_P (decl) || TREE_CODE (decl) == TYPE_DECL)
&& c_type_variably_modified_p (TREE_TYPE (decl)))
@@ -724,6 +729,15 @@ c_print_identifier (FILE *file, tree node, int indent)
c_binding_oracle = save;
}
+/* Establish that the scope contains declarations that are sensitive to
+ jumps that cross a binding. Together with decl_jump_unsafe, this is
+ used to diagnose such jumps. */
+void
+c_mark_decl_jump_unsafe_in_current_scope ()
+{
+ current_scope->has_jump_unsafe_decl = 1;
+}
+
/* Establish a binding between NAME, an IDENTIFIER_NODE, and DECL,
which may be any of several kinds of DECL or TYPE or error_mark_node,
in the scope SCOPE. */
@@ -3974,6 +3988,9 @@ warn_about_goto (location_t goto_loc, tree label, tree decl)
if (c_type_variably_modified_p (TREE_TYPE (decl)))
error_at (goto_loc,
"jump into scope of identifier with variably modified type");
+ else if (flag_openmp
+ && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
+error_at (goto_loc, "jump skips OpenMP % allocation");
else
if (!warning_at (goto_loc, OPT_Wjump_misses_init,
"jump skips variable initialization"))
@@ -4253,6 +4270,15 @@ c_check_switch_jump_warnings (struct c_spot_bindings *switch_bindings,
"variably modified type"));
emitted = true;
}
+ else if (flag_openmp
+ && lookup_attribute ("omp allocate",
+ DECL_ATTRIBUTES (b->decl)))
+ {
+ saw_error = true;
+ error_at
Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)
On Mon, 2023-09-11 at 13:54 +0200, Jakub Jelinek wrote:
> Hi!
>
> One question to David below, CCed.
>
> On Mon, Sep 11, 2023 at 01:44:07PM +0200, Tobias Burnus wrote:
[...]
>
> > +
> > + if (DECL_SOURCE_LOCATION (allocator) >
> > DECL_SOURCE_LOCATION (var))
> > + {
> > + error_at (OMP_CLAUSE_LOCATION (nl),
> > + "allocator variable %qD must be declared
> > before %qD",
> > + allocator, var);
> > + inform (DECL_SOURCE_LOCATION (allocator), "declared
> > here");
> > + inform (DECL_SOURCE_LOCATION (var), "declared here");
>
> I think this will be confusing to users when the inform is the same
> in both
> cases. I'd use "allocator declared here" in the first case.
>
> And, am really not sure if one can just simply compare location_t
> like that.
> Isn't there some function which determines what source location is
> before
> another one? David?
Indeed, the numerical ordering of location_t values doesn't fully
correspond to declaration order.
Please use
linemap_compare_locations
or
linemap_location_before_p
>
> > + if (EXPR_LOCATION (*l) < DECL_SOURCE_LOCATION
> > (var))
> > + break;
>
> Likewise.
>
Dave
>
Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)
Hi!
One question to David below, CCed.
On Mon, Sep 11, 2023 at 01:44:07PM +0200, Tobias Burnus wrote:
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -681,6 +681,11 @@ decl_jump_unsafe (tree decl)
>if (VAR_P (decl) && C_DECL_COMPOUND_LITERAL_P (decl))
> return false;
>
> + if (flag_openmp
> + && VAR_P (decl)
> + && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
> +return true;
> +
>/* Always warn about crossing variably modified types. */
>if ((VAR_P (decl) || TREE_CODE (decl) == TYPE_DECL)
>&& c_type_variably_modified_p (TREE_TYPE (decl)))
> @@ -724,6 +729,12 @@ c_print_identifier (FILE *file, tree node, int indent)
>c_binding_oracle = save;
> }
>
I think we want a function comment here.
> +void
> +c_mark_decl_jump_unsafe_in_current_scope ()
> +{
> + current_scope->has_jump_unsafe_decl = 1;
> +}
> +
> + if (DECL_SOURCE_LOCATION (allocator) > DECL_SOURCE_LOCATION (var))
> + {
> + error_at (OMP_CLAUSE_LOCATION (nl),
> + "allocator variable %qD must be declared before %qD",
> + allocator, var);
> + inform (DECL_SOURCE_LOCATION (allocator), "declared here");
> + inform (DECL_SOURCE_LOCATION (var), "declared here");
I think this will be confusing to users when the inform is the same in both
cases. I'd use "allocator declared here" in the first case.
And, am really not sure if one can just simply compare location_t like that.
Isn't there some function which determines what source location is before
another one? David?
> + if (EXPR_LOCATION (*l) < DECL_SOURCE_LOCATION (var))
> +break;
Likewise.
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/allocate-12.c
> @@ -0,0 +1,46 @@
> +/* TODO: enable for C++ once implemented. */
> +/* { dg-do compile { target c } } */
> +
> +typedef enum omp_allocator_handle_t
I think all the c-c++-common tests declaring
omp_allocator_handle_t should have
#if __cplusplus >= 201103L
: __UINTPTR_TYPE__
#endif
here (even if they are just { target c } for now, we'd certainly
forget to adjust them).
Jakub
[Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)
The patch adds more check and fixes some minor FE bits, but it now has a
'sorry' for automatic/stack variables in the middle end.
I think it is useful by itself as it completes the C FE part and adds
diagnostic, even if the actual code generation is disabled.
Comments, remarks, suggestions?
The actual code generation works fine (see previous patch) but it fails
with OpenMP privatization and mapping; I have locally an incomplete WIP
patch to fix this. But until it works, the 'sorry' makes more sense.
Besides solving that issue, C++ needs to be updated to be on par with C
and my (not yet posted) Fortran patch also needs some changes for the C
and ME changes.
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
OpenMP (C only): omp allocate - extend parsing support, improve diagnostic
The 'allocate' directive can be used for both stack and static variables.
While the parser in C and C++ was pre-existing, it missed several
diagnostics, which this commit adds - for now only for C.
While the "sorry, unimplemented" for static variables is still issues
during parsing, the sorry for stack variables is now issued in the
middle end, preparing for the actual implementation. (Again: only for C.)
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_construct): Move call to
c_parser_omp_allocate to ...
(c_parser_pragma): ... here.
(c_parser_omp_allocate): Avoid ICE is allocator could not be
parsed; set 'omp allocate' attribute for stack/automatic variables
and only reject static variables; add several additional
restriction checks.
* c-tree.h (c_mark_decl_jump_unsafe_in_current_scope): New prototype.
* c-decl.cc (decl_jump_unsafe): Return true for omp-allocated decls.
(c_mark_decl_jump_unsafe_in_current_scope): New.
(warn_about_goto, c_check_switch_jump_warnings): Add error for
omp-allocated decls.
gcc/ChangeLog:
* gimplify.cc (gimplify_bind_expr): Check for
insertion after variable cleanup. Convert 'omp allocate'
var-decl attribute to GOMP_alloc/GOMP_free calls.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/allocate-5.c: Fix testcase; make some
dg-messages for 'sorry' as c++, only.
* c-c++-common/gomp/directive-1.c: Make a 'sorry' c++ only.
* c-c++-common/gomp/allocate-9.c: New test.
* c-c++-common/gomp/allocate-11.c: New test.
* c-c++-common/gomp/allocate-12.c: New test.
* c-c++-common/gomp/allocate-14.c: New test.
* c-c++-common/gomp/allocate-15.c: New test.
gcc/c/c-decl.cc | 23 ++
gcc/c/c-parser.cc | 112 +++---
gcc/c/c-tree.h| 1 +
gcc/gimplify.cc | 40 +
gcc/testsuite/c-c++-common/gomp/allocate-11.c | 40 +
gcc/testsuite/c-c++-common/gomp/allocate-12.c | 46 +++
gcc/testsuite/c-c++-common/gomp/allocate-14.c | 26 ++
gcc/testsuite/c-c++-common/gomp/allocate-15.c | 28 +++
gcc/testsuite/c-c++-common/gomp/allocate-5.c | 60 +++---
gcc/testsuite/c-c++-common/gomp/allocate-9.c | 96 ++
gcc/testsuite/c-c++-common/gomp/directive-1.c | 2 +-
11 files changed, 432 insertions(+), 42 deletions(-)
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 649c5ae66c2..05fdb9240ae 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -681,6 +681,11 @@ decl_jump_unsafe (tree decl)
if (VAR_P (decl) && C_DECL_COMPOUND_LITERAL_P (decl))
return false;
+ if (flag_openmp
+ && VAR_P (decl)
+ && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
+return true;
+
/* Always warn about crossing variably modified types. */
if ((VAR_P (decl) || TREE_CODE (decl) == TYPE_DECL)
&& c_type_variably_modified_p (TREE_TYPE (decl)))
@@ -724,6 +729,12 @@ c_print_identifier (FILE *file, tree node, int indent)
c_binding_oracle = save;
}
+void
+c_mark_decl_jump_unsafe_in_current_scope ()
+{
+ current_scope->has_jump_unsafe_decl = 1;
+}
+
/* Establish a binding between NAME, an IDENTIFIER_NODE, and DECL,
which may be any of several kinds of DECL or TYPE or error_mark_node,
in the scope SCOPE. */
@@ -3974,6 +3985,9 @@ warn_about_goto (location_t goto_loc, tree label, tree decl)
if (c_type_variably_modified_p (TREE_TYPE (decl)))
error_at (goto_loc,
"jump into scope of identifier with variably modified type");
+ else if (flag_openmp
+ && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
+error_at (goto_loc, "jump skips OpenMP % allocation");
else
if (!warning_at (goto_loc, OPT_Wjump_misses_init,
"jump skips variable initialization"))
@@ -4253,6 +4267,15 @@ c_check_switch_jump_warnings (struct c_spot_bindings *switch_bindings,
"variably modified type"));
emitted = true;
}
+
Re: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic
Attached is an incremental patch to add diagnostic for the in-between
allocator issues, i.e.
On 30.08.23 12:47, Tobias Burnus wrote:
omp_allocator_handle_t uninit;
int var, var2;
uninit = omp_low_lat_mem_alloc;
omp_allocator_handle_t late_declared = omp_low_lat_mem_alloc;
#pragma omp allocate(var) allocator(uninit)
#pragma omp allocate(var) allocator(late_declared)
Further comments, remarks and suggestions to this patch - or the base
patch (v2 in previous email) are highly welcome.
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
OpenMP (C only): omp allocate - improve diagnostic regarding the allocator
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_allocate): Diagnose when allocator
is declared or modified between the declaration of a list item
and the 'omp allocate' directive.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/allocate-5.c: Fix testcase.
* c-c++-common/gomp/allocate-12.c: New test.
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index dcc5de7ad93..dfef61da082 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -19445,6 +19445,44 @@ c_parser_omp_allocate (c_parser *parser)
"%qD not yet supported", var);
continue;
}
+ if (allocator
+ && TREE_CODE (allocator) == VAR_DECL
+ && c_check_in_current_scope (var))
+ {
+ if (DECL_SOURCE_LOCATION (allocator) > DECL_SOURCE_LOCATION (var))
+ {
+ error_at (OMP_CLAUSE_LOCATION (nl),
+ "allocator variable %qD must be declared before %qD",
+ allocator, var);
+ inform (DECL_SOURCE_LOCATION (allocator), "declared here");
+ inform (DECL_SOURCE_LOCATION (var), "declared here");
+ }
+ else
+ {
+ gcc_assert (cur_stmt_list
+ && TREE_CODE (cur_stmt_list) == STATEMENT_LIST);
+ tree_stmt_iterator l = tsi_last (cur_stmt_list);
+ while (!tsi_end_p (l))
+ {
+ if (EXPR_LOCATION (*l) < DECL_SOURCE_LOCATION (var))
+ break;
+ if (TREE_CODE (*l) == MODIFY_EXPR
+ && TREE_OPERAND (*l, 0) == allocator)
+ {
+ error_at (EXPR_LOCATION (*l),
+ "allocator variable %qD, used in the "
+ "% directive for %qD, must not be "
+ "modified between declaration of %qD and its "
+ "% directive",
+ allocator, var, var);
+ inform (DECL_SOURCE_LOCATION (var), "declared here");
+ inform (OMP_CLAUSE_LOCATION (nl), "used here");
+ break;
+ }
+ --l;
+ }
+ }
+ }
DECL_ATTRIBUTES (var) = tree_cons (get_identifier ("omp allocate"),
build_tree_list (allocator, alignment),
DECL_ATTRIBUTES (var));
diff --git a/gcc/testsuite/c-c++-common/gomp/allocate-5.c b/gcc/testsuite/c-c++-common/gomp/allocate-5.c
index de1efc6832d..2ca4786264f 100644
--- a/gcc/testsuite/c-c++-common/gomp/allocate-5.c
+++ b/gcc/testsuite/c-c++-common/gomp/allocate-5.c
@@ -18,9 +18,9 @@ typedef enum omp_allocator_handle_t
void
foo ()
{
+ omp_allocator_handle_t my_allocator = omp_default_mem_alloc;
int a, b;
static int c;
- omp_allocator_handle_t my_allocator;
#pragma omp allocate (a) /* { dg-message "sorry, unimplemented: '#pragma omp allocate' not yet supported" "" { target c++ } } */
#pragma omp allocate (b) allocator(my_allocator) /* { dg-message "sorry, unimplemented: '#pragma omp allocate' not yet supported" "" { target c++ } } */
#pragma omp allocate(c) align(32)
diff --git a/gcc/testsuite/c-c++-common/gomp/allocate-12.c b/gcc/testsuite/c-c++-common/gomp/allocate-12.c
new file mode 100644
index 000..38836ef5089
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/allocate-12.c
@@ -0,0 +1,43 @@
+/* TODO: enable for C++ once implemented. */
+/* { dg-do compile { target c } } */
+
+typedef enum omp_allocator_handle_t
+{
+ omp_default_mem_alloc = 1,
+ omp_low_lat_mem_alloc = 5,
+ __omp_allocator_handle_t_max__ = __UINTPTR_MAX__
+} omp_allocator_handle_t;
+
+int
+f ()
+{
+ omp_allocator_handle_t my_allocator;
+ int n = 5; /* { dg-note "declared here" } */
+ my_allocator = omp_default_mem_alloc; /* { dg-error "allocator variable 'my_allocator' must not be modified between declaration of 'n' and its 'allocate' directive" } */
+ #pragma omp allocate(n) allocator(my_allocator) /* { dg-note "used here" } */
+ n = 7;
+ return n;
+}
+
+
+int
+g ()
+{
+ int n = 5; /* { dg-note "declared here" } */
+ omp_allocator_handle_t my_allocator = omp_low_lat_mem_alloc; /* { dg-note "declared here" } */
+ #pragma omp allocate(n) allocator(my_allocator) /* { dg-error "allocator variable 'my_allocator' must be declared before 'n'" } */
+ n = 7;
+ return n;
+}
+
+int
+h ()
+{
+ /* my_allocator uninitialized - but only diagnosed in the ME with -Wuninitialized;
+ see gomp/allocate-10.c. */
+ omp_allocator_handle_t my_allocator;
+ int n = 5;
+
Re: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic
On Wed, Aug 30, 2023 at 12:47:42PM +0200, Tobias Burnus wrote: > > For switches, there is the case of the switch jumping across declaration > > of an automatic var which is not initialized/constructed (I think in that > > case there is normally no warning/error and happens a lot in the wild > > including GCC sources) but perhaps one could treat those cases with > > #pragma omp allocate as if they are actually constructed (though, I'd still > > raise it at OpenMP F2F), > Can you open an OpenMP spec issue? https://github.com/OpenMP/spec/issues/3676 Feel freeo to amend it. Jakub
Re: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic
Revised patch included - addresses part of the issues:
* gimplify.cc: Fix placement of GOMP_alloc by really checking for
DECL_EXPR (experimented with it before but settled
for a different pattern)
* c/ Add it to has_jump_unsafe_decl similar to VLA
+ added msg to the switch/goto error handling.
+ new c-c++-common/gomp/allocate-11.c testcase for it
But not all discussion points are solved, yet. Namely,
how to diagnose:
omp_allocator_handle_t uninit;
int var, var2;
uninit = omp_low_lat_mem_alloc;
omp_allocator_handle_t late_declared = omp_low_lat_mem_alloc;
#pragma omp allocate(var) allocator(uninit)
#pragma omp allocate(var) allocator(late_declared)
(Currently, it is only diagnosed with -Wuninitialized (or -Wextra).)
Otherwise, I think all is covered, but I might have missed something.
Regarding:
On 29.08.23 19:14, Jakub Jelinek wrote:
What about
int n = 5;
omp_allocator_handle_t my_allocator = omp_low_lat_mem_alloc;
#pragma omp allocate(n) allocator(my_allocator)
? What we do in that case? Is that invalid because my_allocator
isn't in scope when n is defined?
IMHO yes - as we can always construct cases with loops in the
execution-order dependence.
The current implementation handles it as VLA,
i.e. warning (VLA vs. allocator):
foo.c:5:3: warning: ‘m’ is used uninitialized [-Wuninitialized]
5 | int A[m];
| ^~~
foo.c:7:7: warning: ‘my_allocator’ is used uninitialized [-Wuninitialized]
7 | int n = 5;
As this is more surprising than VLA, it is probably worth an error
and a more explicit error. The question is how to best detect that
the allocator is either declared after the to-be-omp-allocated variable
declaration or that it is declared before but the assignment happens
only after the declaration (either before 'omp allocate' or not).
I wonder how to best check for this. During parsing, we can check for
TREE_USE and whether an initializer exists, for DECL_EXPR and for
c_check_in_current_scope, but this is not sufficient. We could use
DECL_SOURCE_LOCATION () with '<' comparisons, but I am not sure how it
plays with #line and #include - nor will it catch:
int var;
allocator = ...
#pragma omp allocate(var) allocator(allocator)
where 'allocator' is TREE_USED and declared before 'var' but still wrong.
The 'is used initialized' is done deep in the middle end, but I don't think
we want to add some flag_openmp always-run special case there.
[Admittedly, we do not need to catch all issues and -Wuninitialized, enabled
by -Wextra, will also find this usage. Still, we should try to diagnose the
most common issues.]
Well, in this case the warning is there just because the patch chose to put
it at the start of the BIND_EXPR rather than right before DECL_EXPR.
Granted; the way the code before the DECL_EXPR was found wasn't ideal; I
now changed it back to what I previously had - where for C++, I need to
handle also a cleanup_point_expr around DECL_EXPR.
For switches, there is the case of the switch jumping across declaration
of an automatic var which is not initialized/constructed (I think in that
case there is normally no warning/error and happens a lot in the wild
including GCC sources) but perhaps one could treat those cases with
#pragma omp allocate as if they are actually constructed (though, I'd still
raise it at OpenMP F2F),
Can you open an OpenMP spec issue?
and another case with switch which doesn't even do
that.
Consider
switch (i)
{
case 42:
bar ();
break;
case 51:
int j = 5;
use ();
break;
}
This is valid for both C and C++, one doesn't jump across any initialization
in there. Yet if the j allocation is done at the start of the BIND_EXPR, it
will jump across that initialization.
With the previously posted patch (and also the current one), that yields:
:
D.2900 = __builtin_GOMP_alloc (0, 4, 0B);
*D.2900 = 5;
which looks fine to me.
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
OpenMP (C only): omp allocate - handle stack vars, improve diagnostic
The 'allocate' directive can be used for both stack and static variables.
While the parser in C and C++ was pre-existing, it missed several
diagnostics, which this commit adds - for now only for C.
Additionally, it stopped with a sorry after parsing.
For C only, the sorry is now restricted to static variables, the stack
variable declarations are now tagged by the 'omp allocate' attribute and
in gimplify_bind_expr the GOMP_alloc/GOMP_free allocation will now be
added.
Follow up: Add the same parser additions for C++ and update the testcases.
And add Fortran support, where also parsing support exists, where also
diagnostic updates are required.
gcc/c/ChangeLog:
* c-parser.cc
Re: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic
On Tue, Aug 29, 2023 at 06:56:40PM +0200, Tobias Burnus wrote:
> On 29.08.23 18:28, Jakub Jelinek wrote:
> > One thing is that for C++ one needs to be careful about vars optimized
> > by NRV by the FE.
> Thanks for the warning.
> > And, just from the gimplify_bind_expr function name,
>
> (I forgot that one change in there which makes it look larger is that
> I moved the stack handling below the variable cleaning as it makes sense
> to GOMP_free before instead of after wiping the stack via
> __builtin_stack_restore.)
>
> > I'm guessing you are adding the allocations at the start of surrounding
> > BIND_EXPR, is that where
> > we generally want to allocate them?
>
> I actually started with this in a FE implementation, but that
> does not work in general. I need to put the GOMP_alloc right
> before the associated DECL_EXPR, otherwise, it will break for
> code like:
>
> omp_allocator_handle_t my_allocator = omp_low_lat_mem_alloc;
> int n = 5;
> pragma omp allocate(n) allocator(my_allocator)
What about
int n = 5;
omp_allocator_handle_t my_allocator = omp_low_lat_mem_alloc;
#pragma omp allocate(n) allocator(my_allocator)
? What we do in that case? Is that invalid because my_allocator
isn't in scope when n is defined?
> For your example, I get (the full gimple dump is below):
>
> foo.c:7:11: warning: statement will never be executed [-Wswitch-unreachable]
> 7 | int j;
>
> I wonder whether we should just error out as GCC does when using a VLA
> at that place:
>
> error: switch jumps into scope of identifier with variably modified type
>
> (with a similar but modified msg wording.) In a sense, the 'allocate' is very
> similar to VLA such that we should be able to piggyback on the VLA diagnostic.
Well, in this case the warning is there just because the patch chose to put
it at the start of the BIND_EXPR rather than right before DECL_EXPR.
For switches, there is the case of the switch jumping across declaration
of an automatic var which is not initialized/constructed (I think in that
case there is normally no warning/error and happens a lot in the wild
including GCC sources) but perhaps one could treat those cases with
#pragma omp allocate as if they are actually constructed (though, I'd still
raise it at OpenMP F2F), and another case with switch which doesn't even do
that.
Consider
switch (i)
{
case 42:
bar ();
break;
case 51:
int j = 5;
use ();
break;
}
This is valid for both C and C++, one doesn't jump across any initialization
in there. Yet if the j allocation is done at the start of the BIND_EXPR, it
will jump across that initialization.
So, to me this feels like we should treat for the crossing initialization
stuff vars mentioned in allocate directive as having a non-trivial
constructor.
If you add default: break; before } above, C++ will reject it with an error,
but C will accept it, it is up to the user to initialize the var again in C
or not use it.
And, as I said earlier, this isn't just about switch, but user gotos as
well.
Jakub
Re: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic
On 29.08.23 18:28, Jakub Jelinek wrote:
One thing is that for C++ one needs to be careful about vars optimized
by NRV by the FE.
Thanks for the warning.
And, just from the gimplify_bind_expr function name,
(I forgot that one change in there which makes it look larger is that
I moved the stack handling below the variable cleaning as it makes sense
to GOMP_free before instead of after wiping the stack via
__builtin_stack_restore.)
I'm guessing you are adding the allocations at the start of surrounding
BIND_EXPR, is that where
we generally want to allocate them?
I actually started with this in a FE implementation, but that
does not work in general. I need to put the GOMP_alloc right
before the associated DECL_EXPR, otherwise, it will break for
code like:
omp_allocator_handle_t my_allocator = omp_low_lat_mem_alloc;
int n = 5;
pragma omp allocate(n) allocator(my_allocator)
int B[n]
where my_allocator strictly needs to be (initialized) before
GOMP_alloc and the 'n = 5' - but that needs in turn to happen
before the 'int B[n]' to make sure 'n' is allocated and has
the value 5.
Other option is on DECL_EXPR, e.g. for C++ right before they are
constructed, or for C initialized if they have initializer. Though, that
can have a drawback, one can e.g. in C (and I think in C++ too as long as
the vars don't need any kind of construction) jump across that
initialization and one would then bypass this allocation.
For your example, I get (the full gimple dump is below):
foo.c:7:11: warning: statement will never be executed [-Wswitch-unreachable]
7 | int j;
I wonder whether we should just error out as GCC does when using a VLA
at that place:
error: switch jumps into scope of identifier with variably modified type
(with a similar but modified msg wording.) In a sense, the 'allocate' is very
similar to VLA such that we should be able to piggyback on the VLA diagnostic.
Tobias
PS: The gimple dump for your program:
void foo (int i)
{
switch (i) , case 42: >
{
int j [value-expr: *D.2899];
try
{
D.2899 = __builtin_GOMP_alloc (0, 4, 0B);
:
*D.2899 = 5;
use (D.2899);
goto ;
:
*D.2899 = 24;
use (D.2899);
goto ;
}
finally
{
__builtin_GOMP_free (D.2899, 0B);
}
}
:
}
-
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
Re: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic
On Tue, Aug 29, 2023 at 06:12:58PM +0200, Tobias Burnus wrote:
> This adds support for
> #pragma omp allocate(var-list) [allocator(..) align(..)]
>
> While the spec permits stack and static variables, this patch only
> adds support for stack variables - keeping the 'sorry' for static
> variables.
> It is also only C as I wanted to get this out before updating C++
> parsing. However, if disable the 'sorry' + add the attribute, it
> will also work for C++.
>
> For Fortran, there is no expression associated with the declaration
> such that it will not work with the gimplify.cc patch (it cannot
> find the place to add it); however, I have a mostly working version
> for FE generated support for stack _and_ static variables.
>
> The main RFC question for this patch is whether to generate the
> GOMP_alloc/free calls also for !TREE_USED() or not. This patch avoids
> this to aid removal of such stack variables, but one could also argue
> otherwise.
>
> Thoughts, comments, remarks?
Don't have time to look through it in detail right now, so just
2 quick comments.
One thing is that for C++ one needs to be careful about vars optimized
by NRV by the FE. Dunno if we can simply disregard vars mentioned
in allocate directive from FE NRV, or whether we instead should ignore
the allocate directive, or sorry, etc. Because NRV optimized vars
are turned into RESULT_DECL and live usually in the caller's stack frame
rather than current function, so they can't be heap allocated...
And, just from the gimplify_bind_expr function name, I'm guessing you are
adding the allocations at the start of surrounding BIND_EXPR, is that where
we generally want to allocate them?
Other option is on DECL_EXPR, e.g. for C++ right before they are
constructed, or for C initialized if they have initializer. Though, that
can have a drawback, one can e.g. in C (and I think in C++ too as long as
the vars don't need any kind of construction) jump across that
initialization and one would then bypass this allocation. Though, what
happens with say
void
foo (int i)
{
switch (i)
{
int j;
#pragma omp allocate (j) ...
case 42:
j = 5;
use ();
break;
default:
j = 24;
use ();
break;
}
}
Where will j be allocated and where will j be deallocated with your patch?
If it is try/finally, then perhaps break; as jump out of the BIND_EXPR will
destruct it fine, but I have no idea how it would work when jumping into the
switch (or goto into middle of some compound statement etc.).
Jakub
[Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic
This adds support for
#pragma omp allocate(var-list) [allocator(..) align(..)]
While the spec permits stack and static variables, this patch only
adds support for stack variables - keeping the 'sorry' for static
variables.
It is also only C as I wanted to get this out before updating C++
parsing. However, if disable the 'sorry' + add the attribute, it
will also work for C++.
For Fortran, there is no expression associated with the declaration
such that it will not work with the gimplify.cc patch (it cannot
find the place to add it); however, I have a mostly working version
for FE generated support for stack _and_ static variables.
The main RFC question for this patch is whether to generate the
GOMP_alloc/free calls also for !TREE_USED() or not. This patch avoids
this to aid removal of such stack variables, but one could also argue
otherwise.
Thoughts, comments, remarks?
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
OpenMP (C only): omp allocate - handle stack vars, improve diagnostic
The 'allocate' directive can be used for both stack and static variables.
While the parser in C and C++ was pre-existing, it missed several
diagnostics, which this commit adds - for now only for C.
Additionally, it stopped with a sorry after parsing.
For C only, the sorry is now restricted to static variables, the stack
variable declarations are now tagged by the 'omp allocate' attribute and
in gimplify_bind_expr the GOMP_alloc/GOMP_free allocation will now be
added.
Follow up: Add the same parser additions for C++ and update the testcases.
And add Fortran support, where also parsing support exists, where also
diagnostic updates are required.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_construct): Move call to
c_parser_omp_allocate to ...
(c_parser_pragma): ... here.
(c_parser_omp_allocate): Avoid ICE is allocator could not
be parsed; set 'omp allocate' attribute for stack variables
and only reject stack variables; add several additional
restriction checks.
gcc/ChangeLog:
* gimplify.cc (gimplify_bind_expr): Convert 'omp allocate'
var-decl attribute to GOMP_alloc/GOMP_free calls.
libgomp/ChangeLog:
* libgomp.texi (Impl.Status): Mark allocate directive as 'P'.
(OMP_ALLOCATOR): Fix name of ICV variable.
* testsuite/libgomp.c-c++-common/allocate-4.c: New test.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/allocate-5.c: Fix testcase; make some
dg-messages for 'sorry' as c++, only.
* c-c++-common/gomp/directive-1.c: Make a 'sorry' c++ only.
* c-c++-common/gomp/allocate-10.c: New test.
* c-c++-common/gomp/allocate-9.c: New test.
gcc/c/c-parser.cc | 73 ++---
gcc/gimplify.cc| 82 +++
gcc/testsuite/c-c++-common/gomp/allocate-10.c | 46 +++
gcc/testsuite/c-c++-common/gomp/allocate-5.c | 58 ++---
gcc/testsuite/c-c++-common/gomp/allocate-9.c | 94 ++
gcc/testsuite/c-c++-common/gomp/directive-1.c | 2 +-
libgomp/libgomp.texi | 7 +-
.../testsuite/libgomp.c-c++-common/allocate-4.c| 75 +
8 files changed, 377 insertions(+), 60 deletions(-)
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index cae10ba9c80..a04fd474a28 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -1679,6 +1679,7 @@ static bool c_parser_omp_declare (c_parser *, enum pragma_context);
static void c_parser_omp_requires (c_parser *);
static bool c_parser_omp_error (c_parser *, enum pragma_context);
static void c_parser_omp_assumption_clauses (c_parser *, bool);
+static void c_parser_omp_allocate (c_parser *);
static void c_parser_omp_assumes (c_parser *);
static bool c_parser_omp_ordered (c_parser *, enum pragma_context, bool *);
static void c_parser_oacc_routine (c_parser *, enum pragma_context);
@@ -13620,6 +13621,10 @@ c_parser_pragma (c_parser *parser, enum pragma_context context, bool *if_p)
c_parser_omp_requires (parser);
return false;
+case PRAGMA_OMP_ALLOCATE:
+ c_parser_omp_allocate (parser);
+ return false;
+
case PRAGMA_OMP_ASSUMES:
if (context != pragma_external)
{
@@ -19316,10 +19321,13 @@ c_parser_oacc_wait (location_t loc, c_parser *parser, char *p_name)
align (constant-expression)] */
static void
-c_parser_omp_allocate (location_t loc, c_parser *parser)
+c_parser_omp_allocate (c_parser *parser)
{
tree alignment = NULL_TREE;
tree allocator = NULL_TREE;
+ c_parser_consume_pragma (parser);
+ location_t loc = c_parser_peek_token (parser)->location;
+ location_t allocator_loc = UNKNOWN_LOCATION;
tree nl = c_parser_omp_var_list_parens (parser, OMP_CLAUSE_ALLOCATE, NULL_TREE);
do
{
@@ -19344,7 +19352,9 @@
