This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]