Re: [PATCH] Fix component mappings with derived types for OpenACC

2020-06-04 Thread Julian Brown
On Tue, 19 May 2020 14:23:34 +0200 Thomas Schwinge wrote: > Hi! > > On 2020-01-28T13:41:00+, Julian Brown > wrote: > > On Fri, 24 Jan 2020 10:58:49 +0100 > > Tobias Burnus wrote: > >> the gfortran part is rather obvious and it and the test case look > >> fine to me → OK. > >> The

Re: [PATCH] Fix component mappings with derived types for OpenACC

2020-05-19 Thread Thomas Schwinge
Hi! On 2020-01-28T13:41:00+, Julian Brown wrote: > On Fri, 24 Jan 2020 10:58:49 +0100 > Tobias Burnus 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

Re: [PATCH] Fix component mappings with derived types for OpenACC

2020-01-28 Thread Julian Brown
On Fri, 24 Jan 2020 10:58:49 +0100 Tobias Burnus wrote: > Hi Julian, > > 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

Re: [PATCH] Fix component mappings with derived types for OpenACC

2020-01-24 Thread Tobias Burnus
Hi Julian, 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. Tobias On 1/10/20 2:49 AM, Julian Brown wrote: This patch fixes a bug with mapping Fortran components (i.e. with the

[PATCH] Fix component mappings with derived types for OpenACC

2020-01-09 Thread Julian Brown
Hi, This patch fixes a bug with mapping Fortran components (i.e. with the manual deep-copy support) which themselves have derived types. I've also added a couple of new tests to make sure such mappings are lowered correctly, and to check for the case that Tobias found in the message: