https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123252
Christopher Albert <albert at tugraz dot at> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |albert at tugraz dot at
--- Comment #2 from Christopher Albert <albert at tugraz dot at> ---
Created attachment 63122
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63122&action=edit
gimplify: copy Fortran derived-type scalars for OpenACC enter data
When !$acc enter data copyin(c%arr(...)) maps only an allocatable component of
a Fortran derived type, GCC’s gimplification still creates a GOMP_MAP_STRUCT
mapping for the enclosing derived object. Before the attached patch, that
struct mapping did not also ensure that scalar, non-pointer components of the
derived type (e.g. c%flag or c%n) were copied to the device. As a result, later
device kernels could observe those scalar fields as garbage and take the wrong
branch.
The patch teaches omp_accumulate_sibling_list (in gcc/gimplify.cc) to, for
OpenACC enter data in the Fortran front end, synthesize map(to:) entries for
eligible scalar fields ofthe derived type when the triggering mapping is a
to/copyin-style map (GOMP_MAP_TO_PSET or any kind with GOMP_MAP_FLAG_TO). The
newly created scalar member mappings are inserted into the GOMP_MAP_STRUCT
member list in ascending field-offset order, and any Fortran descriptor-related
nodes that follow the member list are preserved.
New regression tests:
- gcc/testsuite/gfortran.dg/goacc/pr123252-scalar-field-mapping.f90
-
gcc/testsuite/gfortran.dg/goacc/pr123255-allocatable-component-map-order.f90
