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.
