[PATCH 6/9] [OpenACC] Set bias to zero for explicit attach/detach clauses in C and C++

[Julian Brown]

On Thu, 9 Jul 2020 23:06:29 +0200
Thomas Schwinge <thomas@codesourcery.com> wrote:

> 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.)

Do the 7th & 8th patches in this series help? They were "supposed to"
be the Fortran equivalent of these C/C++ changes, though I found
additional problems too.

Thanks,

Julian