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

login
register
mail settings
Submitter Janus Weil
Date Aug. 4, 2010, 6:44 p.m.
Message ID <AANLkTi=3KzBXESWJB6Qv9PBaZJxqCqf_o+ya79Cg-eVd@mail.gmail.com>
Download mbox | patch
Permalink /patch/60882/
State New
Headers show

Comments

Janus Weil - Aug. 4, 2010, 6:44 p.m.
>> 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:


Will commit after another regtest.

Cheers,
Janus
Janus Weil - Aug. 4, 2010, 7:52 p.m.
2010/8/4 Janus Weil <janus@gcc.gnu.org>:
>>> 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.


Committed as r162879:

http://gcc.gnu.org/viewcvs?view=revision&revision=162879

Cheers,
Janus

Patch

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;