From patchwork Mon Jan 3 22:48:22 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Janus Weil X-Patchwork-Id: 77352 Return-Path: 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 12116B6EE8 for ; Tue, 4 Jan 2011 09:48:33 +1100 (EST) Received: (qmail 24108 invoked by alias); 3 Jan 2011 22:48:31 -0000 Received: (qmail 24090 invoked by uid 22791); 3 Jan 2011 22:48:31 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RFC_ABUSE_POST 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; Mon, 03 Jan 2011 22:48:26 +0000 Received: by bwz10 with SMTP id 10so13975801bwz.20 for ; Mon, 03 Jan 2011 14:48:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.71.141 with SMTP id h13mr4135190bkj.180.1294094902353; Mon, 03 Jan 2011 14:48:22 -0800 (PST) Received: by 10.204.7.13 with HTTP; Mon, 3 Jan 2011 14:48:22 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Jan 2011 23:48:22 +0100 Message-ID: Subject: Re: [Patch, Fortran, OOP] PR 46448: [4.6 Regression] symbol `__copy_...' is already defined From: Janus Weil To: gfortran , gcc-patches Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Ok, since no one has dared yet to criticize my patch, I'll start with some self-criticism: The patch as posted does fix the test case in comment #0 of the PR, but only if it comes in a single file (as in class_34.f90). Otherwise, if I put the modules/main program into separate files and compile them via gfortran-4.6 m0.f90 m1.f90 m2.f90 p.f90 I still get: /tmp/ccWGdkZv.o: In function `__copy_m0_t_': m2.f90:(.text+0x0): multiple definition of `__copy_m0_t_' /tmp/cc6cc0qj.o:m1.f90:(.text+0x6d): first defined here Fortunately there is a workaround for this: It is cured by using -fwhole-program. However, we probably do not want OOP codes to rely on non-default switches like -fwhole-program. One simple alternative that just came to my mind: The whole problem would go away if the __copy_ routine would undergo the same name mangling as all standard module procedures, i.e. getting a prefix like "__m1_" or "__m2_". When looking for the reason, I came up with the attached two-line patch, which seems to fix the issue for both the single-file as well as multi-file setup, and is much simpler than the previous approach (not regtested yet). Cheers, Janus 2011/1/3 Janus Weil : > Hi all, > > here is a patch to fix a recent OOP regression. It avoids duplication > of the '__copy_...' routines (which are used for polymorphic > allocation with source) by adding global symbols for those routines. > > The patch also introduces a new function called 'gfc_add_gsymbol', > which is used to add symbols to gfortran's list of global symbols > (gfc_gsym_root). It replaces various other functions like > 'add_global_entry', 'add_global_procedure' and 'add_global_program', > which all did basically the same thing. The new function also includes > an 'ns' argument. This is needed for the __copy_ routines, since these > do go into the gfc_current_ns namespace. > > The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? > > Cheers, > Janus > > > 2011-01-03  Janus Weil   > >        PR fortran/46448 >        * gfortran.h (gfc_add_gsymbol): New prototype. >        * class.c (gfc_find_derived_vtab): Add a global symbol for the copying >        routine to avoid duplication. >        * decl.c (add_global_entry): Removed. >        (gfc_match_entry): Use 'gfc_add_gsymbol' instead of 'add_global_entry'. >        * parse.c (add_global_procedure,add_global_program): Removed. >        (parse_block_data,parse_module,gfc_parse_file): Use 'gfc_add_gsymbol'. >        * symbol.c (gfc_add_gsymbol): New function for adding global symbols, >        replacing 'add_global_entry', 'add_global_procedure' and >        'add_global_program'. > > > 2011-01-03  Janus Weil   > >        PR fortran/46448 >        * gfortran.dg/class_34.f90: New. > Index: gcc/fortran/class.c =================================================================== --- gcc/fortran/class.c (revision 168424) +++ gcc/fortran/class.c (working copy) @@ -528,6 +528,8 @@ gfc_find_derived_vtab (gfc_symbol *derived) sub_ns->proc_name = copy; copy->attr.flavor = FL_PROCEDURE; copy->attr.if_source = IFSRC_DECL; + if (ns->proc_name->attr.flavor == FL_MODULE) + copy->module = ns->proc_name->name; gfc_set_sym_referenced (copy); /* Set up formal arguments. */ gfc_get_symbol ("src", sub_ns, &src);