Re: [PATCH 00/13] OpenACC 2.6 manual deep copy support

[Julian Brown <julian@codesourcery.com>]

On Wed, 18 Dec 2019 18:44:04 +0100
Thomas Schwinge <thomas@codesourcery.com> wrote:

> Hi!
> 
> On 2019-12-17T22:02:25-0800, Julian Brown <julian@codesourcery.com>
> wrote:
> > This patch series provides support for OpenACC 2.6's manual deep
> > copy (attach/detach) feature.  
> 
> Thanks.
> 
> 
> There is high pressure to get this functionality into GCC 10, but
> remaining time is short, given upcoming winter holidays, and GCC
> development stage 3 end.  The big "OpenACC reference count overhaul"
> is a prerequisite for the actual "OpenACC 2.6 manual deep copy
> support". Integrating into GCC trunk in incremental pieces these
> changes has taken a considerable amount of time, due to having to
> research a lot of the existing GCC implementation as well as intended
> semantics.  While we made good progress, it's not complete yet.  I
> very much would like to continue working this in an incremental
> fashion, however, due to shortage of time, this is not possible.
> Under protest I thus now rubber-stamp approve all the patches posted
> here (to the extent I'm able to), without further review now, and I'm
> planning to next year then do post-commit review, and revisions as
> required.

Thanks. I'm committing the following patches:

  Use aux struct in libgomp for infrequently-used/API-specific data
  OpenACC reference count overhaul
  Use gomp_map_val for OpenACC host-to-device address translation
  Factor out duplicate code in gimplify_scan_omp_clauses
  OpenACC 2.6 deep copy: attach/detach API routines
  OpenACC 2.6 deep copy: libgomp parts
  OpenACC 2.6 deep copy: middle-end parts
  OpenACC 2.6 deep copy: C and C++ front-end parts
  OpenACC 2.6 deep copy: Fortran front-end parts
  OpenACC 2.6 deep copy: C and C++ execution tests
  OpenACC 2.6 deep copy: Fortran execution tests
  Fortran polymorphic class-type support for OpenACC

I've omitted the "OpenACC reference count consistency checking" patch
for now. A couple of patches needed readjusting for code that landed on
trunk since my last rebase/repost (in particular "Use gomp_map_val..."
and "OpenACC reference count overhaul"), so I've attempted to fix those
in the lowest-impact way possible to avoid regressions. Apologies for
any oversights!

Additionally I've made some improvements suggested by Tobias in the
Fortran front-end patch (thanks!).

(An earlier iteration of the deep copy patches were submitted
previously at the end of 2018, and were approved by Jakub -- pending
approval by Thomas. See
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01292.html. I hope
Thomas's rubber stamp, plus that email, are sufficient to allow this
code into mainline.)

> > Many of these patches have been submitted
> > previously, but this series has been rebased and the large deep-copy
> > part proper has been split into several pieces for ease of review.  
> 
> Again: at least as far as I'm concerned, "ease of review" doesn't
> mean to artificially split a patch into several pieces per component
> or directories/files touched (I don't need separate patches for
> 'libgomp.oacc-c-c++-common/', and then 'libgomp.oacc-fortran/'), but
> instead per self-contained functional change, incrementally.

Understood, but some split-out parts fall under other individual
reviewers' areas of responsibility (e.g. the Fortran front-end stuff).
Plus the big patch was getting kind of unwieldy.

Cheers (and happy Christmas everyone!),

Julian