Re: [Patch, Fortran, OOP] PR 42207/44064/44065: Undefined reference to vtab$...

[Tobias Burnus <burnus at net-b dot de>]

 On 08/04/2010 03:57 PM, Janus Weil wrote:
> 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?

Tobias

> 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.