https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112475
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> I admit I haven't paid much attention what the latest OpenMP standard
> currently requires for virtual method calls.
OpenMP 5.0 "2.12.5 target Construct" [175:25-26] has:
"The effect of invoking a virtual member function of an object on a device
other than the device on which the object was constructed is implementation
defined"
BTW: The "5.0" testcase of sollve_vv (see comment 0) does inside the target
region:
ptr = new S1();
which looks fine (valid 5.0).
* * *
In OpenMP 5.1, I cannot find anything :-/
* * *
OpenMP 5.2 [287:8-14] has in "13.8 target Construct" the following; note the
second bullet point:
"-------- C++ ---------------
• The run-time type information (RTTI) of an object can only be accessed from
the device on which it was constructed.
• Invoking a virtual member function of an object on a device other than the
device on which the object was constructed results in unspecified behavior,
unless the object is accessible and was constructed on the host device.
• If an object of polymorphic class type is destructed, virtual member
functions of any previously existing corresponding objects in other device data
environments must not be invoked."
* * *
Thus, besides the dynamic allocation inside the device region, we need to
handle since 5.2 also the case the class instance was created on the host.
In either case, we need to have the virtual table on the device side (and all
relevant member functions, the latter should be the case due to the delimited
'declare target').
For the cases that a class was instantiated on the host and is used on the
device side, we need to:
(a) convert the host pointer to a device pointer for the vtable
(b) and then the pointers to the member functions in the vtable.
For the latter, we already have support for 'indirect' where
fun_ptr ();
is automatically converted (on the device side, only) to
GOMP_target_map_indirect_ptr (fun_ptr) ();
Thus, on the 'declare' side, the 'vtable' needs to be handled as well (created
on the device + have an 'indirect') - and, the easier part, 'declare target'
for virtual functions must automatically imply 'indirect'.
And on the usage side, GOMP_target_map_indirect_ptr calls have to be inserted
both for the vtable access and the member function access via the vtable.
