This patches is the ME part to support OpenMP 5.0's deep-mapping
feature, i.e. mapping allocatable components of Fortran's derived types
automatically. [Not the lang hooks but allocatate-array part will probably
also be useful when later adding 'iterator'-modifier support to the
'map'/'to'/'from' clauses.]

This is a belated real submission of the patch sent in March 2022,
   https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591144.html
(with FE fixes at https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593562.html
   (note to self: Bernhard did sent some comment fixes off list)
+ https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593704.html )
+ ME fix for OpenACC at https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603906.html
[which is in the attach patch]

As written, attached is the ME part. Below is a description how
it is supposed to get used; the patch links above show how it looks
in the real-code FE.


======================
BACKGROUND
======================

Fortran permits

type t
   integer, allocatable :: x, y(:)
end type t
type t2
   type(t2), allocatable :: previous_stack  ! Not valid in OMP 5.0
   integer, allocatable :: a
   type(t) :: b, c(:)
end type t2
type(t2) :: var1, var2(:)

!$omp target enter data(var1, var2)

Where all allocatable components need to be mapped alongside. The number of
mappings is only known at runtime, e.g. for 'var2' - the array size is only
known at runtime and then each allocatable component of each element of
'var2' needs to be mapped - both those can contain allocatable components as
well, which have to be mapped - but of course only if the parent component
is actually allocated.

  * * *

The current code puts 'kinds' with const values into an array, 'sizes' in
a fixed-size stack array (either with const or dynamic values) and 'addrs'
is a struct.

To support deep mapping, those all have to be dynamic; hence, the arrays
'sizes' and 'kinds' are turned into pointers - and the 'struct' gets a
tailing variable-size array, which is then filled with the dynamic content.

For this purpose, three lang hooks are added - all are called rather late,
i.e. during omp-low.cc, such that all previous operations (implicit mapping,
explicit mapping, OpenMP mapper) are already done.

* First one to check whether there is any allocatable component for a map-clause
   element (explicitly or implicitly added). If not, the current code is used.
   Otherwise, it uses dynamically allocated arrays
(Side note: As the size is now only known at runtime, TREE_VEC has now another
  element - the array size - hence the change to expand_omp_target, before it
  was known statically from the type.)

* Second hook to actually count how many allocations are done, required for
   the allocation.

* Third hook to actually fill the arrays.


Comments? Remarks?

Tobias

PS: There are two things to watch out in the future:
- 'mapper': I think it should work when the mapper is present as it comes rather
   late in the flow, but I have not checked with Julian's patches (pending review).
- Order: the dynamic items are added last to 'addrs' to permit keeping the 'struct'
   type. I think that's fine for allocatable components as they are added rather late
   and accessing them via 'is_device_ptr' is not possible.
   But there might be some issues with 'interator' in future; something to watch out.
   If so, we may need to partially or fully give up on putting all others mappings stillinto
   the struct.
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955