From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8128 invoked by alias); 4 Aug 2010 15:08:41 -0000 Received: (qmail 8058 invoked by uid 22791); 4 Aug 2010 15:08:39 -0000 X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,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 15:08:33 +0000 Received: by bwz10 with SMTP id 10so3370119bwz.20 for ; Wed, 04 Aug 2010 08:08:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.143.138 with SMTP id v10mr6244980bku.133.1280934510228; Wed, 04 Aug 2010 08:08:30 -0700 (PDT) Received: by 10.204.16.76 with HTTP; Wed, 4 Aug 2010 08:08:30 -0700 (PDT) In-Reply-To: <4C59798B.7040507@net-b.de> References: <4C59798B.7040507@net-b.de> Date: Wed, 04 Aug 2010 15:08:00 -0000 Message-ID: Subject: Re: [Patch, Fortran, OOP] PR 42207/44064/44065: Undefined reference to vtab$... From: Janus Weil To: Tobias Burnus Cc: gfortran , gcc-patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00304.txt.bz2 >> Regtested on x86_64-unknown-linux-gnu. Ok for trunk? > > The patch looks OK. However, I was wondering, when reading > > + =A0if (code->ext.alloc.ts.type =3D=3D BT_DERIVED) > + =A0 =A0gfc_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 =A0Janus Weil >> >> =A0 =A0 =A0 =A0PR fortran/42207 >> =A0 =A0 =A0 =A0PR fortran/44064 >> =A0 =A0 =A0 =A0PR fortran/44065 >> =A0 =A0 =A0 =A0* class.c (gfc_find_derived_vtab): Do not generate vtabs = for class >> =A0 =A0 =A0 =A0container types. Do not artificially increase refs. Commi= t symbols >> one >> =A0 =A0 =A0 =A0by one. >> =A0 =A0 =A0 =A0* interface.c (compare_parameter): Make sure vtabs are pr= esent >> before >> =A0 =A0 =A0 =A0generating module variables. >> =A0 =A0 =A0 =A0* resolve.c (resolve_allocate_expr): Ditto. >> >> >> 2010-08-04 =A0Janus Weil >> >> =A0 =A0 =A0 =A0PR fortran/42207 >> =A0 =A0 =A0 =A0PR fortran/44064 >> =A0 =A0 =A0 =A0PR fortran/44065 >> =A0 =A0 =A0 =A0* gfortran.dg/class_25.f03: New. >> =A0 =A0 =A0 =A0* gfortran.dg/class_26.f03: New. >