Re: [PATCH, OpenACC] Support C++ "this" in OpenACC directives (PR66053)
On 9/3/18 7:50 PM, Julian Brown wrote: On Fri, 31 Aug 2018 16:20:08 +0200 Jakub Jelinek wrote: On Fri, Aug 31, 2018 at 10:04:07AM -0400, Nathan Sidwell wrote: On 08/30/2018 04:27 PM, Jason Merrill wrote: On Thu, Aug 30, 2018 at 3:31 PM, Julian Brown wrote: "Apart from parsing, it's necessary to prevent the "cannot take the address of 'this', which is an rvalue expression" error from appearing Breaking a rather fundamental language attribute does not seem wise. Why does referring to this[0:1] require making 'this' addressable? Surely what we're interested in is the value of 'this', not the address. Yes, transferring the this pointer is very unlikely to be what the user wants -- the object being referred to contains the data. It might be wise to look at the DR's and changes relating to lambdas and this capture. Those changes now make it much harder to simply capture the pointer unintentionally. Yeah, I agree we shouldn't try to make this addressable. Does OpenACC try to map the base of the array section (rather than what e.g. OpenMP does, privatize the pointer base instead and assign the pointer the new value inside of the region)? Even if it is mapped, can't it be mapped by taking an address of a temporary initialized from this? For OpenACC, two mappings are created for an array section: one for the data (to, from, tofrom, etc.) and a firstprivate pointer with a bias to locate the (possibly virtual) zero'th element of the array. I think that's the same as OpenMP. For the test case given, it's sufficient to merely allow "this" to be used as the base pointer for an array section. That usage doesn't require "this" to be made addressable. The this[0:1] syntax is accepted by PGI (https://www.pgroup.com/resources/docs/18.4/x86/openacc-gs/index.htm, 2.4 C++ Classes in OpenACC) -- in order to copy "the class itself" to the accelerator. Referring to class member variables in OpenACC clauses (as the example in that section does also) is still problematic in GCC, though. PGI also allows the user to specify just "this" in OpenACC clauses, which presumably does the same thing as specifying this[0:1]. For PGI, but not for OpenACC <= 2.5, that seems to follow a general case for pointers to structs (2.3. C Structs in OpenACC), "A pointer to a scalar struct is treated as a one-element array, and should be shaped as r[0:1]". That's notably different from OpenMP 4.5, which treats plain mapped pointers as zero-length array sections, and also differs from the current behaviour of GCC (which bizarrely, IIUC, is to copy the bits of the host pointer verbatim to the target). OpenACC 2.5 arguably leaves the behaviour unspecified for pointers without an explicit array section. The attached patch allows basic class-wrapping-an-array kinds of usages, anyway. Re-tested with offloading to nvptx and bootstrapped. OK to apply? Thanks, Julian 2018-09-03 Joseph Myers Julian Brown PR C++/66053 * semantics.c (handle_omp_array_sections_1): Allow array sections with "this" pointer for OpenACC. OK. Jason
Re: [PATCH, OpenACC] Support C++ "this" in OpenACC directives (PR66053)
On Fri, 31 Aug 2018 16:20:08 +0200
Jakub Jelinek wrote:
> On Fri, Aug 31, 2018 at 10:04:07AM -0400, Nathan Sidwell wrote:
> > On 08/30/2018 04:27 PM, Jason Merrill wrote:
> >
> > > On Thu, Aug 30, 2018 at 3:31 PM, Julian Brown
> > > wrote:
> > > > "Apart from parsing, it's necessary to prevent the "cannot take
> > > > the address of 'this', which is an rvalue expression" error
> > > > from appearing
> >
> > Breaking a rather fundamental language attribute does not seem wise.
> >
> > > Why does referring to this[0:1] require making 'this' addressable?
> > > Surely what we're interested in is the value of 'this', not the
> > > address.
> > Yes, transferring the this pointer is very unlikely to be what the
> > user wants -- the object being referred to contains the data. It
> > might be wise to look at the DR's and changes relating to lambdas
> > and this capture. Those changes now make it much harder to simply
> > capture the pointer unintentionally.
>
> Yeah, I agree we shouldn't try to make this addressable.
> Does OpenACC try to map the base of the array section (rather than
> what e.g. OpenMP does, privatize the pointer base instead and assign
> the pointer the new value inside of the region)?
> Even if it is mapped, can't it be mapped by taking an address of a
> temporary initialized from this?
For OpenACC, two mappings are created for an array section: one for the
data (to, from, tofrom, etc.) and a firstprivate pointer with a bias to
locate the (possibly virtual) zero'th element of the array. I think
that's the same as OpenMP.
For the test case given, it's sufficient to merely allow "this" to be
used as the base pointer for an array section. That usage doesn't
require "this" to be made addressable.
The this[0:1] syntax is accepted by PGI
(https://www.pgroup.com/resources/docs/18.4/x86/openacc-gs/index.htm,
2.4 C++ Classes in OpenACC) -- in order to copy "the class itself" to
the accelerator.
Referring to class member variables in OpenACC clauses (as the example
in that section does also) is still problematic in GCC, though.
PGI also allows the user to specify just "this" in OpenACC clauses,
which presumably does the same thing as specifying this[0:1]. For PGI,
but not for OpenACC <= 2.5, that seems to follow a general case for
pointers to structs (2.3. C Structs in OpenACC), "A pointer to a scalar
struct is treated as a one-element array, and should be shaped as
r[0:1]". That's notably different from OpenMP 4.5, which treats plain
mapped pointers as zero-length array sections, and also differs from
the current behaviour of GCC (which bizarrely, IIUC, is to copy the
bits of the host pointer verbatim to the target). OpenACC 2.5 arguably
leaves the behaviour unspecified for pointers without an explicit array
section.
The attached patch allows basic class-wrapping-an-array kinds of
usages, anyway. Re-tested with offloading to nvptx and bootstrapped. OK
to apply?
Thanks,
Julian
2018-09-03 Joseph Myers
Julian Brown
PR C++/66053
* semantics.c (handle_omp_array_sections_1): Allow array
sections with "this" pointer for OpenACC.
commit 355411e5415f65e09a06f42d400761fff065f7c7
Author: Julian Brown
Date: Fri Aug 31 17:30:20 2018 -0700
Allow this[:] array slices for OpenACC
2018-09-03 Joseph Myers
Julian Brown
* semantics.c (handle_omp_array_sections_1): Allow array sections with
"this" pointer for OpenACC.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 676de01..98511ed 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -4598,7 +4598,8 @@ handle_omp_array_sections_1 (tree c, tree t, vec &types,
omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
return error_mark_node;
}
- else if (TREE_CODE (t) == PARM_DECL
+ else if (ort == C_ORT_OMP
+ && TREE_CODE (t) == PARM_DECL
&& DECL_ARTIFICIAL (t)
&& DECL_NAME (t) == this_identifier)
{
diff --git a/libgomp/testsuite/libgomp.oacc-c++/this.C b/libgomp/testsuite/libgomp.oacc-c++/this.C
new file mode 100644
index 000..510c690
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c++/this.C
@@ -0,0 +1,43 @@
+#include
+#include
+using namespace std;
+
+class test {
+ public:
+ int a;
+
+ test ()
+ {
+a = -1;
+#pragma acc enter data copyin (this[0:1])
+ }
+
+ ~test ()
+ {
+#pragma acc exit data delete (this[0:1])
+ }
+
+ void set (int i)
+ {
+a = i;
+#pragma acc update device (this[0:1])
+ }
+
+ int get ()
+ {
+#pragma acc update host (this[0:1])
+return a;
+ }
+};
+
+int
+main ()
+{
+ test t;
+
+ t.set (4);
+ if (t.get () != 4)
+abort ();
+
+ return 0;
+}
Re: [PATCH, OpenACC] Support C++ "this" in OpenACC directives (PR66053)
On Fri, Aug 31, 2018 at 10:04:07AM -0400, Nathan Sidwell wrote: > On 08/30/2018 04:27 PM, Jason Merrill wrote: > > > On Thu, Aug 30, 2018 at 3:31 PM, Julian Brown > > wrote: > > > > > "Apart from parsing, it's necessary to prevent the "cannot take the > > > address of 'this', which is an rvalue expression" error from appearing > > Breaking a rather fundamental language attribute does not seem wise. > > > Why does referring to this[0:1] require making 'this' addressable? > > Surely what we're interested in is the value of 'this', not the > > address. > Yes, transferring the this pointer is very unlikely to be what the user > wants -- the object being referred to contains the data. It might be wise > to look at the DR's and changes relating to lambdas and this capture. Those > changes now make it much harder to simply capture the pointer > unintentionally. Yeah, I agree we shouldn't try to make this addressable. Does OpenACC try to map the base of the array section (rather than what e.g. OpenMP does, privatize the pointer base instead and assign the pointer the new value inside of the region)? Even if it is mapped, can't it be mapped by taking an address of a temporary initialized from this? Jakub
Re: [PATCH, OpenACC] Support C++ "this" in OpenACC directives (PR66053)
On 08/30/2018 04:27 PM, Jason Merrill wrote: On Thu, Aug 30, 2018 at 3:31 PM, Julian Brown wrote: "Apart from parsing, it's necessary to prevent the "cannot take the address of 'this', which is an rvalue expression" error from appearing Breaking a rather fundamental language attribute does not seem wise. Why does referring to this[0:1] require making 'this' addressable? Surely what we're interested in is the value of 'this', not the address. Yes, transferring the this pointer is very unlikely to be what the user wants -- the object being referred to contains the data. It might be wise to look at the DR's and changes relating to lambdas and this capture. Those changes now make it much harder to simply capture the pointer unintentionally. nathan -- Nathan Sidwell
Re: [PATCH, OpenACC] Support C++ "this" in OpenACC directives (PR66053)
On Thu, Aug 30, 2018 at 3:31 PM, Julian Brown wrote: > This patch (by Joseph) allows "this" to be used in OpenACC directives, > following -- IIUC -- the behaviour of other compilers. The standard (as > of OpenACC 2.5) does not appear to have explicit language either > permitting or forbidding such usage. > > Joseph's original commentary is in the bug report (ca. 2015, > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66053): > > "This patch, for gomp-4_0-branch, adds support for C++ "this" in > OpenACC directives. (This patch does not do anything to handle OpenMP > differently from OpenACC; that - bug 66053 - will need to be resolved > for mainline, either deciding these cases should be accepted for > OpenMP or making the parsing only accept them in OpenACC directives > and not OpenMP ones.) > > "Apart from parsing, it's necessary to prevent the "cannot take the > address of 'this', which is an rvalue expression" error from appearing > when "this" is used in such contexts. This patch duly adds a new > argument to cxx_mark_addressable (default false so callers don't all > need to change) to allow disabling that error, passing that argument > in all calls that seem relevant to OpenACC directives." > > AFAICT though, this attached version of the patch does still forbid > "this" in OpenMP directives (apart from "declare simd"). I couldn't see > that there was any change to the OpenMP spec language in 4.5. > > Tested with offloading to NVPTX and bootstrapped. > > OK to apply? > > Julian > > ChangeLog > > 20xx-xx-xx Joseph Myers > > PR C++/66053 > > gcc/cp/ > * cp-tree.h (enum cxx_mark_addressable_flags): New. > (cxx_mark_addressable): Use it. Adjust users. > * parser.c (cp_parser_omp_var_list_no_open): Handle RID_THIS. > * semantics.c (handle_omp_array_sections_1) > (handle_omp_array_sections, finish_omp_reduction_clause) > (finish_omp_clauses): Pass CXX_MARK_ADDRESSABLE_FLAGS_ALLOW_THIS > to cxx_mark_addressable. Enforce "this" usage limitation only > for OpenMP. > * typeck.c (cp_build_array_ref): Adjust cxx_mark_addressble > call. (cxx_mark_addressable): Handle > CXX_MARK_ADDRESSABLE_FLAGS_ALLOW_THIS. > > libgomp/ > * testsuite/libgomp.oacc-c++/this.C: New test. Why does referring to this[0:1] require making 'this' addressable? Surely what we're interested in is the value of 'this', not the address. Jason
[PATCH, OpenACC] Support C++ "this" in OpenACC directives (PR66053)
This patch (by Joseph) allows "this" to be used in OpenACC directives,
following -- IIUC -- the behaviour of other compilers. The standard (as
of OpenACC 2.5) does not appear to have explicit language either
permitting or forbidding such usage.
Joseph's original commentary is in the bug report (ca. 2015,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66053):
"This patch, for gomp-4_0-branch, adds support for C++ "this" in
OpenACC directives. (This patch does not do anything to handle OpenMP
differently from OpenACC; that - bug 66053 - will need to be resolved
for mainline, either deciding these cases should be accepted for
OpenMP or making the parsing only accept them in OpenACC directives
and not OpenMP ones.)
"Apart from parsing, it's necessary to prevent the "cannot take the
address of 'this', which is an rvalue expression" error from appearing
when "this" is used in such contexts. This patch duly adds a new
argument to cxx_mark_addressable (default false so callers don't all
need to change) to allow disabling that error, passing that argument
in all calls that seem relevant to OpenACC directives."
AFAICT though, this attached version of the patch does still forbid
"this" in OpenMP directives (apart from "declare simd"). I couldn't see
that there was any change to the OpenMP spec language in 4.5.
Tested with offloading to NVPTX and bootstrapped.
OK to apply?
Julian
ChangeLog
20xx-xx-xx Joseph Myers
PR C++/66053
gcc/cp/
* cp-tree.h (enum cxx_mark_addressable_flags): New.
(cxx_mark_addressable): Use it. Adjust users.
* parser.c (cp_parser_omp_var_list_no_open): Handle RID_THIS.
* semantics.c (handle_omp_array_sections_1)
(handle_omp_array_sections, finish_omp_reduction_clause)
(finish_omp_clauses): Pass CXX_MARK_ADDRESSABLE_FLAGS_ALLOW_THIS
to cxx_mark_addressable. Enforce "this" usage limitation only
for OpenMP.
* typeck.c (cp_build_array_ref): Adjust cxx_mark_addressble
call. (cxx_mark_addressable): Handle
CXX_MARK_ADDRESSABLE_FLAGS_ALLOW_THIS.
libgomp/
* testsuite/libgomp.oacc-c++/this.C: New test.
commit 12294a1345d981b72ef61d285057fb4c7e378fd7
Author: Julian Brown
Date: Wed Aug 29 18:19:44 2018 -0700
Support C++ "this" in OpenACC directives
20xx-xx-xx Joseph Myers
PR C++/66053
gcc/cp/
* cp-tree.h (enum cxx_mark_addressable_flags): New.
(cxx_mark_addressable): Use it. Adjust users.
* parser.c (cp_parser_omp_var_list_no_open): Handle RID_THIS.
* semantics.c (handle_omp_array_sections_1)
(handle_omp_array_sections, finish_omp_reduction_clause)
(finish_omp_clauses): Pass CXX_MARK_ADDRESSABLE_FLAGS_ALLOW_THIS
to cxx_mark_addressable. Enforce "this" usage limitation only for
OpenMP.
* typeck.c (cp_build_array_ref): Adjust cxx_mark_addressble call.
(cxx_mark_addressable): Handle CXX_MARK_ADDRESSABLE_FLAGS_ALLOW_THIS.
libgomp/
* testsuite/libgomp.oacc-c++/this.C: New test.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 43e452c..127e15a 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7214,7 +7214,24 @@ extern void cxx_print_error_function (diagnostic_context *,
struct diagnostic_info *);
/* in typeck.c */
-extern bool cxx_mark_addressable (tree, bool = false);
+
+/* Flags for cxx_mark_addressable. */
+
+enum cxx_mark_addressable_flags
+{
+ CXX_MARK_ADDRESSABLE_FLAGS_NONE = 0,
+ /* This is for ARRAY_REF construction - in that case we don't want
+ to look through VIEW_CONVERT_EXPR from VECTOR_TYPE to ARRAY_TYPE,
+ it is fine to use ARRAY_REFs for vector subscripts on vector
+ register variables. */
+ CXX_MARK_ADDRESSABLE_FLAGS_ARRAY_REF = 1 << 0,
+ /* Allow `current_class_ptr' to be addressable. */
+ CXX_MARK_ADDRESSABLE_FLAGS_ALLOW_THIS = 1 << 1
+};
+
+extern bool cxx_mark_addressable (tree,
+ enum cxx_mark_addressable_flags flags
+ = CXX_MARK_ADDRESSABLE_FLAGS_NONE);
extern int string_conv_p (const_tree, const_tree, int);
extern tree cp_truthvalue_conversion (tree);
extern tree condition_conversion (tree);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 92e6b40..0cf2526 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -31726,7 +31726,7 @@ cp_parser_omp_var_list_no_open (cp_parser *parser, enum omp_clause_code kind,
OMP_CLAUSE_CHAIN (u) = list;
list = u;
}
- else
+ else if (decl != error_mark_node)
list = tree_cons (decl, NULL_TREE, list);
get_comma:
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 676de01..9a722df 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -4598,7 +4598,8 @@ handle_omp_array_sections_1 (tree c, tree t, vec &types,
omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
return error_mark_node;
}
- else if (TREE_CODE (t) == PARM_DECL
+ else if (ort == C_ORT_OMP
+ && TREE_CODE (t) == PARM_DECL
