From patchwork Wed Aug  4 18:44:42 2010
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Patchwork-Submitter: Janus Weil <janus@gcc.gnu.org>
X-Patchwork-Id: 60882
Return-Path: 
 <gcc-patches-return-269807-incoming=patchwork.ozlabs.org@gcc.gnu.org>
X-Original-To: incoming@patchwork.ozlabs.org
Delivered-To: patchwork-incoming@bilbo.ozlabs.org
Received: from sourceware.org (server1.sourceware.org [209.132.180.131])
	by ozlabs.org (Postfix) with SMTP id 581A0B6EF7
	for <incoming@patchwork.ozlabs.org>;
	Thu,  5 Aug 2010 04:44:54 +1000 (EST)
Received: (qmail 4691 invoked by alias); 4 Aug 2010 18:44:50 -0000
Received: (qmail 4675 invoked by uid 22791); 4 Aug 2010 18:44:49 -0000
X-SWARE-Spam-Status: No, hits=2.6 required=5.0	tests=AWL, BAYES_00,
	DKIM_SIGNED, DKIM_VALID, FREEMAIL_ENVFROM_END_DIGIT,
	FREEMAIL_FROM, KAM_STOCKTIP, RCVD_IN_DNSWL_NONE
X-Spam-Check-By: sourceware.org
Received: from mail-bw0-f47.google.com (HELO mail-bw0-f47.google.com)
	(209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with
	ESMTP; Wed, 04 Aug 2010 18:44:45 +0000
Received: by bwz10 with SMTP id 10so3499036bwz.20 for <multiple recipients>;
	Wed, 04 Aug 2010 11:44:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.153.10 with SMTP id i10mr6557349bkw.1.1280947482067;
	Wed, 	04 Aug 2010 11:44:42 -0700 (PDT)
Received: by 10.204.16.76 with HTTP; Wed, 4 Aug 2010 11:44:42 -0700 (PDT)
In-Reply-To: <AANLkTin1pjg=jh=QXJPtZHQQ-iV6wz0YzGwyJk45S6UX@mail.gmail.com>
References: <AANLkTikVAGu7eOJUU7BXZBfDw=9p+qmTnBjJOgA=m=5U@mail.gmail.com>
	<4C59798B.7040507@net-b.de>
	<AANLkTin1pjg=jh=QXJPtZHQQ-iV6wz0YzGwyJk45S6UX@mail.gmail.com>
Date: Wed, 4 Aug 2010 20:44:42 +0200
Message-ID: <AANLkTi=3KzBXESWJB6Qv9PBaZJxqCqf_o+ya79Cg-eVd@mail.gmail.com>
Subject: Re: [Patch, Fortran,
	OOP] PR 42207/44064/44065: Undefined reference 	to vtab$...
From: Janus Weil <janus@gcc.gnu.org>
To: Tobias Burnus <burnus@net-b.de>
Cc: gfortran <fortran@gcc.gnu.org>, gcc-patches <gcc-patches@gcc.gnu.org>
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Unsubscribe: 
 <mailto:gcc-patches-unsubscribe-incoming=patchwork.ozlabs.org@gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Delivered-To: mailing list 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;