This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran, OOP] PR 42207/44064/44065: Undefined reference to vtab$...
>> The patch looks OK. However, I was wondering, when reading
>>
>> + ?if (code->ext.alloc.ts.type == BT_DERIVED)
>> + ? ?gfc_find_derived_vtab (code->ext.alloc.ts.u.derived);
>>
>>
>> whether one should not restrict this to extensible types (i.e. those which
>> are neither SEQUENCE nor Bind(C)). One could add such a check to
>> gfc_find_derived_vtab.
>>
>> And for resolve_allocate_expr shouldn't one check whether either the
>> allocatable object or the MOLD is BT_CLASS? I think if neither of them is
>> CLASS, one does not need to take care of the vtab, or does one?
>
> Right. Checking for BT_CLASS also implies that the type is extensible,
> therefore a separate check for extensible types is not necessary. Will
> post an updated patch soon.
I have now modified the hunk in resolve.c to:
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 162868)
+++ gcc/fortran/resolve.c (working copy)
@@ -6554,6 +6554,18 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code
}
}
+ if (e->ts.type == BT_CLASS)
+ {
+ /* Make sure the vtab symbol is present when
+ the module variables are generated. */
+ gfc_typespec ts = e->ts;
+ if (code->expr3)
+ ts = code->expr3->ts;
+ else if (code->ext.alloc.ts.type == BT_DERIVED)
+ ts = code->ext.alloc.ts;
+ gfc_find_derived_vtab (ts.u.derived);
+ }
+
if (pointer || (dimension == 0 && codimension == 0))
goto success;
Will commit after another regtest.
Cheers,
Janus