https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94358
--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> --- To help with OpenACC 'kernels' support, Gergő later submitted for og8 an additional change in <http://mid.mail-archive.com/31e3dfc5-1bbe-0d11-c7c8-16a0cefa0b45@mentor.com> "Rework OpenACC Fortran DO loop initialization", and committed: openacc-gcc-8-branch commit 7c2f3f5c50e029bec704605b065d63273c2425dd Author: Gergö Barany <ge...@codesourcery.com> AuthorDate: Mon Jan 21 03:08:57 2019 -0800 Commit: Gergö Barany <ge...@codesourcery.com> CommitDate: Tue Jan 29 05:21:14 2019 -0800 Rework OpenACC Fortran DO loop initialization Fortran DO loops on arrays with non-constant bounds (like a(lo:hi)) need special setup code to compute the bounds and offsets for the iteration. In an OpenACC region containing multiple loops, this used to be done in a block of code at the start of the region for all of the loops. But the upcoming kernels conversion expects this kind of setup code to immediately precede the corresponding loop, and variables are not mapped correctly otherwise. This patch separates out the initialization part for each loop and places it immediately before the loop. gcc/fortran/ * trans-openmp.c (gfc_privatize_nodesc_array_clauses): Renamed from gfc_privatize_nodesc_arrays, initialization part factored out to... (gfc_reinitialize_privatized_arrays): ... this new function, called... (gfc_trans_omp_do): ... from here for OpenACC loops. libgomp/ * testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90: New test. Reviewed-by: Thomas Schwinge <tho...@codesourcery.com> gcc/fortran/ChangeLog.openacc | 7 +++++++ gcc/fortran/trans-openmp.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------ libgomp/ChangeLog.openacc | 4 ++++ libgomp/testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90 | 36 ++++++++++++++++++++++++++++++++++++ 4 files changed, 97 insertions(+), 36 deletions(-) (I did approve that for the og8 development branch, but had not actually reviewed.) This patch did not make it into og9 either (obviously, as it depends on the other one). Comparing the previous dumps to this "Rework OpenACC Fortran DO loop initialization" variant (no og8 commits reverted): In the 'original' dump, we now again see the 'private' clauses disappear (so, same as in the "baseline" variant) -- yet the re-computation of 'offset.5' as well as 'D.3818' remaining inside the region, "unprivatized". In the 'gimple' dump, we then see 'firstprivate(size.6) firstprivate(offset.5) firstprivate(stride.4) firstprivate(ubound.3) firstprivate(lbound.2) firstprivate(ubound.1) firstprivate(lbound.0)' appear (supposedly due to implicit 'firstprivate' inside OpenACC 'parallel'?) -- huh, that doesn't seem right, given that the point was to avoid all these 'firstprivate' (data transfers)! (..., and for OpenACC 'kernels', these would all be implicit 'copy', thus global device data, slow, and prone to race-conditions -- so, much worse?) That doesn't seem to make sense, and will need further investigation. But let's first concentrate on the "Privatize internal array variables introduced by the fortran FE" changes alone.
