Dear Tobias, I do not see any problem with adding to the vtable; especially with your suggestion of assigning it to a generic function with a function pointer argument. This might be valuable for other future needs, other than OpenMP/OpenACC/coarrays. I would suggest that 'this' and the function pointer are sufficient arguments.
With best regards Paul On 13 June 2014 22:57, Tobias Burnus <bur...@net-b.de> wrote: > 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. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
