On Wed, 18 Dec 2019 18:44:04 +0100 Thomas Schwinge <tho...@codesourcery.com> wrote:
> Hi! > > On 2019-12-17T22:02:25-0800, Julian Brown <jul...@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
