Hi! On Thu, 8 Sep 2016 19:18:30 +0800, Chung-Lin Tang <chunglin_t...@mentor.com> wrote: > On 2016/9/6 8:11 PM, Thomas Schwinge wrote: > > On Mon, 29 Aug 2016 15:46:47 +0800, Chung-Lin Tang > > <clt...@codesourcery.com> wrote: > >> this patch is a port of some changes from gomp-4_0-branch, > >> including adding additional map type handling in OpenACC enter/exit data > >> directives, and some pointer set handling changes. Updated > >> testsuite case are also included. > >> > >> Tested on trunk to ensure no regressions, is this okay for trunk? > > > >> 2016-08-29 Cesar Philippidis <ce...@codesourcery.com> > >> Thomas Schwinge <tho...@codesourcery.com> > >> Chung-Lin Tang <clt...@codesourcery.com> > > > > Maybe I'm misremembering, but I can't remember having been involved in > > this. ;-) > > A part of this was picked from r223178, which you committed to > gomp-4_0-branch.
Heh, right, though that was a commit containing "Assorted OpenACC changes", so merging various changes from our internal development branch, done by several people. Anyway, nothing to waste much time on. ;-) > >> +/* Returns the number of mappings associated with the pointer or pset. > >> PSET > >> + have three mappings, whereas pointer have two. */ > >> + > >> static int > >> -find_pset (int pos, size_t mapnum, unsigned short *kinds) > >> +find_pointer (int pos, size_t mapnum, unsigned short *kinds) > >> { > >> if (pos + 1 >= mapnum) > >> return 0; > >> > >> unsigned char kind = kinds[pos+1] & 0xff; > >> > >> - return kind == GOMP_MAP_TO_PSET; > >> + if (kind == GOMP_MAP_TO_PSET) > >> + return 3; > >> + else if (kind == GOMP_MAP_POINTER) > >> + return 2; > >> + > >> + return 0; > >> } > > > > I'm still confused about that find_pset/find_pointer handling. Why is > > that required? Essentially, that means that GOACC_enter_exit_data is > > skipping over some mappings, right? If yes, why do the front ends > > (Fortran only?) then emit these mappings to begin with, if we're then > > ignoring them in the runtime? > > It's not skipping mappings. GOMP_MAP_PSET uses 3 continuous entries while > GOMP_MAP_POINTER uses 2, see how these are eventually processed together > in gomp_map_vars(). I now see how for the "pointer != 0" case, *the address of* "hostaddrs[i]" etc. is passed to gomp_acc_insert_pointer, which then calls gomp_map_vars. So, you're (or more precisely, those who once committed these changes to our internal development branch) indeed just extend the existing GOMP_MAP_TO_PSET handling to also cover GOMP_MAP_POINTER. This code still doesn't look very pretty generally, but that's not your task to fix, right now. Thus, your patch is back in the queue, waiting for approval. Grüße Thomas