On Tue, 19 May 2020 14:23:34 +0200 Thomas Schwinge <tho...@codesourcery.com> wrote:
> Hi! > > On 2020-01-28T13:41:00+0000, Julian Brown <jul...@codesourcery.com> > wrote: > > On Fri, 24 Jan 2020 10:58:49 +0100 > > Tobias Burnus <tob...@codesourcery.com> wrote: > >> the gfortran part is rather obvious and it and the test case look > >> fine to me → OK. > >> The oacc-mem.c also looks okay, but I assume Thomas needs to > >> rubber-stamp it. > > > > I understand that Thomas is unavailable for the time being, so > > won't be able to use his rubber-stamp powers. I added the offending > > libgomp code to start with though, so I think I can go ahead and > > commit the patch. I'll hold off for 24 hours though in case there > > are any objections (Jakub?). > > So, in the end you didn't commit this, and now we've got the > "un-fixed" OpenACC/Fortran code generation in the GCC 10.1 release, > so have to deal with it in one way or another going forward, > regarding libgomp ABI compatibility. (Ideally), we need to make sure > that "un-fixed" GCC 10.1-built executables continue to work "as good > as before" when dynamically linked/running against "fixed" GCC 10.1+ > shared libraries. > > Do we get such desired behavior by the patch quoted below? In > particular: removing the 'GOMP_MAP_STRUCT' handling code, but leaving > in the empty 'case GOMP_MAP_STRUCT:' as a no-op, so that we don't run > into 'default:' case 'goacc_exit_data_internal UNHANDLED kind'? Is > that sufficient? > > Is my understanding correct that "fixed" GCC won't generate such > 'GOMP_MAP_STRUCT' anymore (I have't studied in detail), and this empty > 'case GOMP_MAP_STRUCT:' only remains in here for backwards > compatibility? In this case, please add a comment to the code, > stating this. Otherwise, please add a comment why "do nothing" is > appropriate for 'GOMP_MAP_STRUCT'. In particular, for both > scenarios, why we don't need to skip the following 'sizes[i]' > mappings? I'm not sure if I got the threading right, but I've now followed up on this discussion here: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547300.html Thanks, Julian
