On Mon, 10 Sep 2018 10:52:47 -0700 Cesar Philippidis <ce...@codesourcery.com> wrote:
> On 09/10/2018 10:37 AM, Jason Merrill wrote: > > On Mon, Sep 10, 2018 at 4:05 AM, Julian Brown > > <jul...@codesourcery.com> wrote: > >> This patch (by Cesar) changes the way C++ references are mapped in > >> OpenACC regions, fixing an ICE in the non-scalar-data.C testcase. > >> > >> Post-patch, references are mapped like this (from the omplower > >> dump): > >> > >> map(force_present:*x [len: 4]) map(firstprivate ref:x [pointer > >> assign, bias: 0]) > >> > >> Tested with offloading to NVPTX and bootstrapped. OK for trunk? > >> > >> Thanks, > >> > >> Julian > >> > >> ChangeLog > >> > >> 2018-09-09 Cesar Philippidis <ce...@codesourcery.com> > >> Julian Brown <jul...@codesourcery.com> > >> > >> PR middle-end/86336 > >> > >> (gimplify_adjust_omp_clauses_1): Update handling of > >> mapping of C++ references. > > > > How is reference handling specified differently between OpenMP and > > OpenACC? It seems strange for them to differ. > > Both OpenACC and OpenMP privatize mapped array pointers on the > accelerator for subarrays in the same way. However, for pointers > without subarrays, OpenMP treats them as zero-length arrays, whereas > OpenACC treats them as ordinary scalars so that the pointer target > will not get remapped on the accelerator (which is odd because > there's a deviceptr clause for that). Scalars in C++ are special, > because references must treated like an array of length one, for lack > of a better terminology. I think it's more accurate to say that OpenACC says nothing about C++ references at all, nor about how unadorned pointers are mapped in copy/copyin/copyout clauses. So arguably we get to choose whatever we want, preferably based on the principle of least surprise. (ICE'ing definitely counts as a surprise!) As noted in a previous email, PGI seems to treat pointers to aggregates specially, mapping them as ptr[0:1], but it's unclear if the same is true for pointers to scalars with their compiler. Neither behaviour seems to be standard-mandated, but this patch extends the idea to references to scalars nonetheless. > > In any case, you shouldn't need to check lang_GNU_CXX since we're > > already calling the langhook. > > Julian, can you look into this? I'm traveling tomorrow. Yes, I'll continue to look at this patch. Thanks, Julian
