Fortran/OpenMP: Fix 'alloc' and 'from' mapping for allocatable components

Even with 'alloc' and map-entering 'from' mapping, the following should hold.
For explicit mapping, that's already the case, this handles the automatical
deep mapping of allocatable components. Namely:
* On the device, the array bounds (of allocated allocatables) must match the
  host, implying 'to' (or 'tofrom') mapping.
* On map exiting, the copying out shall not destroy the unallocated allocation
  status (nor the pointer address of allocated allocatables).

The latter was not a problem for allocated allocatables as for those a pointer
was GOMP_MAP_ATTACHed; however, for unallocated allocatables, before it copied
back device-allocated memory which might not be nullified.

While 'alloc' was not deep-mapped at all, for map-entering 'from', the array
bounds were not set, making allocated derived-type components inaccessible on
the device (and wrong on the host on copy back).

The solution is, first, to deep-map 'alloc' as well and to copy to the device
even with 'alloc' and (map-entering) 'from'. This copying is only done if there
is a scalar (for the unallocated case) or array allocatable directly in the
derived type and then it is shallowly copied; the data pointed to is then again
only alloc'ed, unless it contains in turn allocatables.

gcc/fortran/

	* trans-openmp.cc (gfc_has_alloc_comps): Add 'bool
	shallow_alloc_only=false' arg.
	(gfc_omp_replace_alloc_by_to_mapping): New, call it.
	(gfc_omp_deep_map_kind_p): Return 'true' also for '(present,)alloc'.
	(gfc_omp_deep_mapping_item, gfc_omp_deep_mapping_do): On map entering,
	replace shallowly 'alloc'/'from' by '(from)to' mapping if there are
	allocatable components.

libgomp/

	* testsuite/libgomp.fortran/map-alloc-comp-8.f90: New test.

0 files changed, 0 insertions, 0 deletions