Use the new copyprivate list from omp.single to emit calls to
__kmpc_copyprivate, during the creation of the single operation
in OMPIRBuilder.
This is patch 4 of 4, to add support for COPYPRIVATE in Flang.
Original PR: https://github.com/llvm/llvm-project/pull/73128
[flang] Fix ISO_Fortran_binding.h to work better with C++ code
This stems from working on LANL's "dopey" project --
https://github.com/lanl/dopey.
That project contains C++ code which includes the header file
"ISO_Fortran_binding.h". The dopey code wraps that include with an
'extern "C"' clause since the standard (18.5.1, paragraph 1) says that
the file" shall contain C structure definitions, typedef declarations,
...". But the clang++ compiler emits error messages objecting to the
fact that ISO_Fortran_binding.h contains templates.
This change fixes that by preceding the problematic code in
ISO_Fortran_binding.h with language linkage clauses that specify that
they contain C++ code rather than C code.
In the accompanying test, I needed to account for the fact that some
people build the compiler by doing a `make check-flang`. In this case,
the clang compiler which is required by the test will not be built.
Here's an example of a C++ program that shows the problem:
```
extern "C" {
#include "ISO_Fortran_binding.h"
}
int main() {
return 0;
}
```
This test was updated by me recently, however, the newly
added CHECK-LABEL checks are breaking one of the RHEL
PowerPC buildbots as the functions appear to be generated
slightly different (in this case added attributes I think).
This patch seeks to add an initial lowering for pointers and allocatable variables
captured by implicit and explicit map in Flang OpenMP for Target operations that
take map clauses e.g. Target, Target Update. Target Exit/Enter etc.
Currently this is done by treating the type that lowers to a descriptor
(allocatable/pointer/assumed shape) as a map of a record type (e.g. a structure) as that's
effectively what descriptor types lower to in LLVM-IR and what they're represented as
in the Fortran runtime (written in C/C++). The descriptor effectively lowers to a structure
containing scalar and array elements that represent various aspects of the underlying
data being mapped (lower bound, upper bound, extent being the main ones of interest
in most cases) and a pointer to the allocated data. In this current iteration of the mapping
we map the structure in it's entirety and then attach the underlying data pointer and map
the data to the device, this allows most of the required data to be resident on the device
for use. Currently we do not support the addendum (another block of pointer data), but
it shouldn't be too difficult to extend this to support it.
The MapInfoOp generation for descriptor types is primarily handled in an optimization
pass, where it expands BoxType (descriptor types) map captures into two maps, one for
the structure (scalar elements) and the other for the pointer data (base address) and
links them in a Parent <-> Child relationship. The later lowering processes will then treat
them as a conjoined structure with a pointer member map.
