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 oacc-me
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 unde
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 b
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
ma
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:
https://gc
