From patchwork Wed Aug  4 18:44:42 2010
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: [Fortran,OOP] PR 42207/44064/44065: Undefined reference to vtab$...
Date: Wed, 04 Aug 2010 08:44:42 -0000
From: Janus Weil <janus@gcc.gnu.org>
X-Patchwork-Id: 60882
Message-Id: <AANLkTi=3KzBXESWJB6Qv9PBaZJxqCqf_o+ya79Cg-eVd@mail.gmail.com>
To: Tobias Burnus <burnus@net-b.de>
Cc: gfortran <fortran@gcc.gnu.org>, gcc-patches <gcc-patches@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:


Will commit after another regtest.

Cheers,
Janus


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;