Dear all, dear Jakub,

this patch handles (for target regions)
   firstprivate(array_descriptor)
by not only firstprivatizing the descriptor but also the data
it points to. This is done by turning it in omp-low.cc the clause
into
   firstprivate(descr) firstprivate(descr.data)
and then attaching the latter to the former. That works by
adding an 'attach' after the last firstprivate (and checking
for it in libgomp). The attached-to device address for a
previous (here: the first) firstprivate is obtained by returning
the device address inside the hostaddrs[i] alias omp_arr array,
i.e. the compiler generates:
   omp_arr.1 = &descr;  /* firstprivate */
   omp_arr.2 = descr.data;  /* firstprivate */
   omp_arr.3 = &omp_arr.1;  /* attach; bias: &desc.data-&desc */
and libgomp then knows that the device address is in the
pointer.

Not implemented, but this scheme can also be used for
   type
     integer, allocatable :: A(:),B(:)
   end type
where multiple attachments have to be done to the same
privatized variable.

Side effect: For  has_device_addr(array_descr)  the pre-patch code
changes this to firstprivate – relying on the shallow copying. Thus,
has_device_addr had to be modified to still be shallow.

OK?

* * *

Note: The code is not active for OpenACC. The existing code uses, e.g.,
'goto oacc_firstprivate' – thus, the new code would be
partially active. I went for making it completely inactive for OpenACC
by adding one '!is_gimple_omp_oacc'. I bet that a deep copy would be
also useful for OpenACC, but I have neither checked what the current
code does nor what the OpenACC spec says about this.

* * *

Some crossrefs:
* https://gcc.gnu.org/PR104949 - the PR to this patch.

* has_device_addr + array descriptor, see clarification
for TR11/OpenMP 6 (passed 2nd vote): OpenMP Spec Issue #3180 / Pull Req. #3204
(related to 'firstprivate' above)

* For a pending is_device_ptr(non-c_ptr) -> has_device_addr issue,
see https://gcc.gnu.org/PR105318

* Regarding issues with reallocation of firstprivate, see:
     https://gcc.gnu.org/PR105538
   (Not completely clear whether the code is valid; there are
   rules related (re,de)allocation for data mapping but not
   for firstprivate + issue about deallocation at the end of
   the scope in this case.)
* Regarding array constructors with non-const length but
   constant items, see https://gcc.gnu.org/PR91544
   (and testcase)
* Deep mapping patch (but not firstprivate):
   https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593704.html

Tobias
-----------------
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