From: Thomas Schwinge <thomas@codesourcery.com>
To: Julian Brown <julian@codesourcery.com>
Cc: <gcc-patches@gcc.gnu.org>, Jakub Jelinek <jakub@redhat.com>,
Tobias Burnus <tobias@codesourcery.com>,
<Catherine_Moore@mentor.com>, <fortran@gcc.gnu.org>
Subject: Re: [PATCH 6/9] [OpenACC] Set bias to zero for explicit attach/detach clauses in C and C++
Date: Thu, 9 Jul 2020 23:06:29 +0200 [thread overview]
Message-ID: <87wo3co0tm.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <87a70r1iog.fsf@euler.schwinge.homeip.net>
Hi Julian!
On 2020-06-25T13:36:15+0200, I wrote:
> On 2020-06-16T15:39:42-0700, Julian Brown <julian@codesourcery.com> wrote:
>> This is a fix for the pointer (or array) size inadvertently being used
>> for the bias of attach and detach clauses (PR95270)
>
> Thanks for looking into that one, which had caused my some gray hair.
>
>> for C and C++.
>
> That means, there is no such problem for Fortran? (I haven't run into
> one, just curious.)
Looking into something else, I've now found the very same (?) problem for
Fortran, too. :-| For the following simple testcase, I again do see
non-zero 'bias: 64' for 'enter data attach(data_p)':
program main
use openacc
implicit none
!TODO Per PR96080, data types chosen so that we can create a "pointer object 'data_p'" on the device.
integer, dimension(:), target :: data(1)
integer, dimension(:), pointer :: data_p
!TODO Per PR96080, not using OpenACC/Fortran runtime library routines.
!$acc enter data create(data)
data_p => data
!$acc enter data copyin(data_p)
!$acc enter data attach(data_p)
end program main
..., and the 'attach' fails with 'libgomp: pointer target not mapped for
attach'. It doesn't fail when I force 'bias = 0' in
'gomp_attach_pointer'.
I've tried a bit, but it seems a bit difficult in Fortran to verify (with
'associated(data_p, data)' etc.) what we've actually 'attach'ed: per
PR96080, a 'call acc_update_self(data_p)' may not be doing the expected
thing, and a '!$acc update self(data_p)' per
'libgomp/oacc-parallel.c:GOACC_update' will update the actual data, but
is no-op for 'GOMP_MAP_TO_PSET', 'GOMP_MAP_POINTER'. I've stopped
experimenting with that any further.
So it seems Fortran front end changes will also be required in addition
to the C, C++ front end changes you've come up with. (For avoidance of
doubt: OK to do separately, if you'd like to. Please also reference GCC
PR95270 for these, and include the testcase from above, or something
better.)
Grüße
Thomas
> In principle, yes, for master and releases/gcc-10 branches, but please
> incorporate the following items:
>
>> PR middle-end/95270
>>
>> gcc/c/
>> * c-typeck.c (c_finish_omp_clauses): Set OMP_CLAUSE_SIZE (bias) to zero
>> for standalone attach/detach clauses.
>>
>> gcc/cp/
>> * semantics.c (finish_omp_clauses): Likewise.
>>
>> gcc/testsuite/
>> * c-c++-common/goacc/mdc-1.c: Update expected dump output for zero
>> bias.
>> ---
>> gcc/c/c-typeck.c | 8 ++++++++
>> gcc/cp/semantics.c | 8 ++++++++
>> gcc/testsuite/c-c++-common/goacc/mdc-1.c | 14 +++++++-------
>> 3 files changed, 23 insertions(+), 7 deletions(-)
>
>> --- a/gcc/c/c-typeck.c
>> +++ b/gcc/c/c-typeck.c
>> @@ -14533,6 +14533,10 @@ c_finish_omp_clauses (tree clauses, enum c_omp_region_type ort)
>> }
>> if (c_oacc_check_attachments (c))
>> remove = true;
>> + if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
>> + && (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_ATTACH
>> + || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_DETACH))
>> + OMP_CLAUSE_SIZE (c) = size_zero_node;
>> break;
>> }
>> if (t == error_mark_node)
>> @@ -14546,6 +14550,10 @@ c_finish_omp_clauses (tree clauses, enum c_omp_region_type ort)
>> remove = true;
>> break;
>> }
>> + if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
>> + && (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_ATTACH
>> + || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_DETACH))
>> + OMP_CLAUSE_SIZE (c) = size_zero_node;
>> if (TREE_CODE (t) == COMPONENT_REF
>> && OMP_CLAUSE_CODE (c) != OMP_CLAUSE__CACHE_)
>> {
>
> I cannot comment if these two code paths are good places (and the only
> ones) that need to set 'OMP_CLAUSE_SIZE', so I'll trust you've found the
> best/all places.
>
> Does that override an 'OMP_CLAUSE_SIZE' that was set earlier, or
> initialize it? Maybe the latter, given my comment in
> <https://gcc.gnu.org/PR95270>: "make sure to skip/invalidate the
> 'gcc/gimplify.c:gimplify_scan_omp_clauses' handling"?
>
> Plase add some commentary here in the code, instead of just in the
> ChangeLog, something like: "initialize here, so that gimplify doesn't
> wrongly do so later" (if that's what it is, and in proper language, of
> course).
>
>> --- a/gcc/cp/semantics.c
>> +++ b/gcc/cp/semantics.c
>> @@ -7334,6 +7334,10 @@ finish_omp_clauses (tree clauses, enum c_omp_region_type ort)
>> }
>> if (cp_oacc_check_attachments (c))
>> remove = true;
>> + if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
>> + && (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_ATTACH
>> + || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_DETACH))
>> + OMP_CLAUSE_SIZE (c) = size_zero_node;
>> break;
>> }
>> if (t == error_mark_node)
>> @@ -7347,6 +7351,10 @@ finish_omp_clauses (tree clauses, enum c_omp_region_type ort)
>> remove = true;
>> break;
>> }
>> + if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
>> + && (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_ATTACH
>> + || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_DETACH))
>> + OMP_CLAUSE_SIZE (c) = size_zero_node;
>> if (REFERENCE_REF_P (t)
>> && TREE_CODE (TREE_OPERAND (t, 0)) == COMPONENT_REF)
>> {
>
> Likewise.
>
>> --- a/gcc/testsuite/c-c++-common/goacc/mdc-1.c
>> +++ b/gcc/testsuite/c-c++-common/goacc/mdc-1.c
>
> Obvious.
>
> In <https://gcc.gnu.org/PR95270> I also requested size vs. bias be
> documented in 'include/gomp-constants.h:enum gomp_map_kind'.
>
> Generally, I'm still somewhat confused by the 'bias' usage in libgomp.
> Is it really only used for the *initial* attach, but then (correctly so?)
> ignored for any later ones? Please add some commentary next to the
> respective libgomp code.
>
> Please also include an execution test case, like I had included with
> <https://gcc.gnu.org/PR95270>, for example the two files I'm attaching.
> Ah actually, since the directive variant now no longer fails, please
> merge these into one file, with 'test(bool directive)', and two
> 'test(false)', 'test(true)' calls from 'main'.
>
>
> Grüße
> Thomas
> [ pr95270_-d.c: text/x-csrc ]
> #define DIRECTIVE
> #include "pr95270_-r.c"
> [ pr95270_-r.c: text/x-csrc ]
> // <https://gcc.gnu.org/PR95270>
>
> #include <assert.h>
> #include <openacc.h>
>
> int main()
> {
> int data;
> int *data_p_dev = (int *) acc_create(&data, sizeof data);
> int *data_p = &data;
> acc_copyin(&data_p, sizeof data_p);
>
> #ifdef DIRECTIVE
> # pragma acc enter data attach(data_p)
> #else
> {
> void **ptr = (void **) &data_p;
> acc_attach(ptr);
> }
> #endif
>
> acc_update_self(&data_p, sizeof data_p);
> assert (data_p == data_p_dev);
>
> return 0;
> }
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
next prev parent reply other threads:[~2020-07-09 21:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 22:38 [PATCH 0/9] [OpenACC] Refcounting and manual deep copy improvements Julian Brown
2020-06-16 22:38 ` [PATCH 1/9] [OpenACC] Fortran derived-type mapping fix Julian Brown
2020-06-16 22:38 ` [PATCH 2/9] [OpenACC] GOMP_MAP_ATTACH handling in find_group_last Julian Brown
2020-06-30 12:42 ` Thomas Schwinge
2020-06-16 22:38 ` [PATCH 3/9] [OpenACC] Adjust dynamic reference count semantics Julian Brown
2020-06-30 13:51 ` Thomas Schwinge
2020-07-03 15:41 ` Thomas Schwinge
2020-07-10 12:08 ` Julian Brown
2020-06-16 22:38 ` [PATCH 4/9] [OpenACC] Don't pass kind array via pointer to goacc_enter_datum Julian Brown
2020-06-16 22:39 ` [PATCH 5/9] [OpenACC] Fix incompatible copyout for acc_map_data (PR92843) Julian Brown
2020-06-16 22:39 ` [PATCH 6/9] [OpenACC] Set bias to zero for explicit attach/detach clauses in C and C++ Julian Brown
2020-06-25 11:36 ` Thomas Schwinge
2020-07-09 21:06 ` Thomas Schwinge [this message]
2020-07-09 21:32 ` Julian Brown
2020-06-16 22:39 ` [PATCH 7/9] [OpenACC] Do not strip GOMP_MAP_TO_PSET/GOMP_MAP_POINTER for enter/exit data directives Julian Brown
2020-07-06 16:19 ` Thomas Schwinge
2020-06-16 22:39 ` [PATCH 8/9] [OpenACC] Fix standalone attach for Fortran assumed-shape array pointers Julian Brown
2020-07-14 11:43 ` Thomas Schwinge
2020-07-15 10:28 ` Thomas Schwinge
2020-07-17 11:16 ` Thomas Schwinge
2020-07-27 14:33 ` Julian Brown
2020-07-30 9:53 ` Thomas Schwinge
2020-07-30 20:15 ` Julian Brown
2020-06-16 22:39 ` [PATCH 9/9] [OpenACC] Don't detach for no-op exit data with zero dynamic refcount Julian Brown
2020-07-24 14:18 ` Thomas Schwinge
2020-07-24 22:53 ` Julian Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wo3co0tm.fsf@euler.schwinge.homeip.net \
--to=thomas@codesourcery.com \
--cc=Catherine_Moore@mentor.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=julian@codesourcery.com \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).