[RFC] Fortran: How to handle allocatable polymorphic components with OpenMPv5/OpenACCv3

[Tobias Burnus]

This email is probably a bit premature as the OpenMPv4.0 and OpenACC 
2.0a specs do not seem to handle Fortran 2003's polymorphic variables. 
However, as I am currently thinking how to handle a similar problem for 
Fortran's coarray, I want to raise the issue for OpenMP/OpenACC to see 
whether something should be done in gfortran to solve the problem for 
OpenMP/OpenACC and coarrays at the same time. For coarrays, see also 
https://gcc.gnu.org/ml/fortran/2014-06/msg00132.html

The issue described below occurs when one needs to copy variables which 
are polymorphic or contain components which are polymorphic. That 
applies both to copying them to a thread-local variable or with 
offloading to the memory of an accelerator.

In case of Fortran, doing an assignment of a derived type (record type) 
will also copy the allocatable components, which in turn might have 
again allocatable components. For nonpolymorphic variables, one can 
simply recursively walk through all components and do the copying that 
way. That's how the Fortran FE does for intrinsic assignments – and what 
Jakub's recently committed OpenMPv4.0 patch does.

However, how to handle it for polymorphic types? In case of the 
intrinsic assignment, the variable/component has a pointer to a virtual 
table, which contains a function pointer to the type's copy function.

But how to handle it in case of OpenMP (v4.1?, v5.0?)? One could augment 
the vtable by a function pointer to an function which handles this for 
OpenMP/OpenACC, probably by calling some libgomp library function. In 
case of coarrays, I have (see link above) the same problem: I need to 
add library calls to transfer allocatable components forth to and back 
from a remote process. Thus, I am also thinking of adding a new entry to 
the virtual table

Another issue arises when one mixes code with and without 
-fopenmp/-facc/-fcoarray=lib. One either has to generate the vtable 
entry and function unconditionally – or only with that option, but then 
one might run into corner cases, where the function is not available.

One option* I see is some kind of generic function, which takes as 
additional argument a function pointer; this pointer could point either 
to libgomp or to the coarray library (for -fcoarray=lib), depending on 
the caller. In addition, it avoids issues with dependencies on the 
called library.

What do you think? Would this be a sensible way for 
OpenMPv5/OpenACCv3/coarrays? Or do you see pitfalls with this approach? 
One additional issue would be the way the arguments are passed, which 
one would have to agree on.

Comments? Suggestions? Questions?

Tobias

* The other option is to generate specific functions, but that is not 
only less flexible but also runs into issues like library dependencies. 
Those can be solved with weak symbols and stubs, but that's also not 
very elegant.