On Thu, 9 Jul 2020 23:06:29 +0200 Thomas Schwinge <tho...@codesourcery.com> wrote:
> Hi Julian! > > On 2020-06-25T13:36:15+0200, I wrote: > > On 2020-06-16T15:39:42-0700, Julian Brown <jul...@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
