More testing found more issues. Instead of adding more band aid to the
pre-existing band aid, which was extended before, let's try a different
approach:

Just ensure that all component types are resolved (which includes
finalizers) before continuing with the derived type. This also resolves
the finalizers (but also derived-type procedures) before using it in the
_callback vtable entry (with the deep mapping patch) – or in general:
before creating the vtable.

Committed to OG11 – and stashed for mainline. See attachment.

Tobias

PS: With the deep-mapping patch, the vtable of allocatable DT components
is required. Thus, the _callback code generation tries to get the
associated vtable. That in turned triggered the generation of the
DT-component's vtable, which did fail with an assert, unless it either
does not have finalizers or the type has been resolved before.

On 25.04.22 15:47, Tobias Burnus wrote:
> Found another issue – applied to OG11 as attached. Will include it in
> the mainline patch once Stage1.
>
> (However, I intent to split the original patch (+ follow ups) into
> smaller pieces for mainline incorporation.)
>
> Tobias
>
> On 02.03.22 23:20, Tobias Burnus wrote:
>> Some testing found an issue in class.cc (in the new _callback
>> function) – updated patch attached (long version + interdiff).
>>
>> Tobias
>>
>> (PS: OG11 - original patch was committed as
>> https://gcc.gnu.org/g:98961d3a0ccb02d7d54d2d4dd07cca75473d685a ;
>> follow-up version to be committed in a moment)
>>
>> On 01.03.22 16:34, Tobias Burnus wrote:
>>> Hi all,
>>>
>>> this patch adds support for mapping something like
>>>   type t
>>>     type(t2), allocatable :: a, b(:)
>>>     integer, allocatable :: c, c(:)
>>>   end type t
>>>   type(t), allocatable :: var, var2(:,:)
>>>
>>>   !$omp target enter data map(var, var)
>>>
>>> which does a deep walk of the components at runtime.
>>>
>>> On the ME side, the static addr/size/kinds arrays are
>>> replaced (only if need) by allocatable arrays – which
>>> are then filled by trans-openmp.c.
>>>
>>> All deep-mapping handling happens via the hooks called
>>> late in omp-low.c such that removing mappings or implicitly
>>> added one are handled.
>>>
>>> In principle, there is also code to handle polymorphic
>>> variables (new callback function in vtable + two on-the-fly
>>> generated functions to be used for walking the vtable).
>>>
>>> Issues: None known, but I am sure with experimenting,
>>> more can be found - especially with arrays/array sections
>>> and polymorphism, I expect issues. I did find some on the
>>> way and fixed them - but (see PR refs in testcase -7.f90),
>>> I also found unrelated bugs, which I did not fix ;-)
>>>
>>> Comments? OK for mainline (GCC 13)?
>>>
>>> Tobias
>>>
>>> PS: I will commit this patch to OG11 for further testing.
>>> PPS: Previously discussed at
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586237.html
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955