This is the mail archive of the 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]

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

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


On 13 June 2014 22:57, Tobias Burnus <> 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
> 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

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