This is the mail archive of the gcc-patches@gcc.gnu.org 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: [Patch, Fortran, OOP] PR 42207/44064/44065: Undefined reference to vtab$...


>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> 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.

Cheers,
Janus




>> 2010-08-04 ?Janus Weil<janus@gcc.gnu.org>
>>
>> ? ? ? ?PR fortran/42207
>> ? ? ? ?PR fortran/44064
>> ? ? ? ?PR fortran/44065
>> ? ? ? ?* class.c (gfc_find_derived_vtab): Do not generate vtabs for class
>> ? ? ? ?container types. Do not artificially increase refs. Commit symbols
>> one
>> ? ? ? ?by one.
>> ? ? ? ?* interface.c (compare_parameter): Make sure vtabs are present
>> before
>> ? ? ? ?generating module variables.
>> ? ? ? ?* resolve.c (resolve_allocate_expr): Ditto.
>>
>>
>> 2010-08-04 ?Janus Weil<janus@gcc.gnu.org>
>>
>> ? ? ? ?PR fortran/42207
>> ? ? ? ?PR fortran/44064
>> ? ? ? ?PR fortran/44065
>> ? ? ? ?* gfortran.dg/class_25.f03: New.
>> ? ? ? ?* gfortran.dg/class_26.f03: New.
>


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