From patchwork Wed Aug 29 19:53:46 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 180757 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 4A97D2C00A5 for ; Thu, 30 Aug 2012 05:54:41 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1346874882; h=Comment: DomainKey-Signature:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=/Tk+uGdpM6CD5cmkvw5XReq0tnQ=; b=Oyj44RHvLjmg8kO U32qIBjuIFpphTfOa33e9WiIppstPZmpCCZz4RRXxf//8D6/YTnJ8NyNSwokgzcR dS+/HY7SWCvdzbuvgOtD32Q88YPmfUPv8haZ2YKdOfQpm7/qpLuJkanuhcPJOJkE zK/qPU49Z38lylDHNZDmQ+xTmD4w= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=o7Zz6OtTGpvZA9kd7MID/520Le1CdVY/Jwm9FgtuheZTe1AvqUhrp/d283QqQR gZ40g6klsFupx80M+vBo3avJrnN5fKBXYZCKY343vvbxmPVL/Mmr9m76A2pbjNEM uZxqgsJrmGu7QfMPa35n8p+HhmcITeBLEVdiiRmITXGhY=; Received: (qmail 15862 invoked by alias); 29 Aug 2012 19:54:29 -0000 Received: (qmail 15745 invoked by uid 22791); 29 Aug 2012 19:54:10 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL, BAYES_20, KAM_STOCKGEN, KHOP_THREADED, RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx02.qsc.de (HELO mx02.qsc.de) (213.148.130.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Aug 2012 19:53:50 +0000 Received: from [192.168.178.22] (port-92-204-67-8.dynamic.qsc.de [92.204.67.8]) by mx02.qsc.de (Postfix) with ESMTP id BE2F7279E3; Wed, 29 Aug 2012 21:53:46 +0200 (CEST) Message-ID: <503E734A.3050801@net-b.de> Date: Wed, 29 Aug 2012 21:53:46 +0200 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: gcc patches , gfortran , Alessandro Fanfarillo , "Rouson, Damian" , Mikael Morin Subject: Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine References: <50295E1A.5050108@net-b.de> In-Reply-To: <50295E1A.5050108@net-b.de> 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 Dear all, that's the revised version of patch at http://gcc.gnu.org/ml/fortran/2012-08/msg00095.html, taking the review comments into account. Reminder: This patch only generates the finalization wrapper, which is in the virtual table. It does not add the required calls; hence, it still doesn't allow to use finalization. The patch consists of three parts: a) The main patch, which implements the wrapper. I am asking for approval for that patch. b) A patch which removes the gfc_error "not yet implemented" I suggest to only remove the error after finalization calls have been added c) A patch which bumps the .mod version - or alternatively - a patch which disables the _final generation in the vtable. I have build and regtested (on x86-64-linux) the patch with (a) and (a)+(b) applied. I would like to include the patch (c) as modifying the vtable changes the ABI. Bumping the .mod version is a reliable way to force recompilation. The alternative is to wait until the final FINAL patch before bumping the .mod version (and disable the "_final" generation). One possibility, if deemed useful, is to combine the .mod version bump with backward compatible reading of .mod files, i.e., only error out when BT_CLASS is encountered in an old .mod file. Is the patch (a) OK for the trunk? With which version of (c)? (I am slightly inclined to do the .mod bump now. As a follow up, one can also commit Janus' proc-pointer patch, http://gcc.gnu.org/ml/fortran/2012-04/msg00033.html, though I think someone has still to review it.) Tobias PS: When doing the ABI change, I am going to document it in the release notes / wiki. ------------------------------------------------------- NOTE: Only one of the two patchlets should be committed not both! ------------------------------------------------------- 2012-08-19 Alessandro Fanfarillo Tobias Burnus PR fortran/37336 * module.c (MOD_VERSION): Bump to for recompilation after the vtable ABI has changed. * class.c (gfc_find_derived_vtab): Disable the FINAL wrapper generation. diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 9d58aab..8c51302 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -1624,13 +1624,14 @@ gfc_find_derived_vtab (gfc_symbol *derived) Note: The actual wrapper function can only be generated at resolution time. */ + /* TODO: Enabled when FINAL is implemented. */ if (gfc_add_component (vtype, "_final", &c) == FAILURE) goto cleanup; c->attr.proc_pointer = 1; c->attr.access = ACCESS_PRIVATE; c->tb = XCNEW (gfc_typebound_proc); c->tb->ppc = 1; - generate_finalization_wrapper (derived, ns, tname, c); + generate_finalization_wrapper (derived, ns, tname, c);*/ /* Add procedure pointers for type-bound procedures. */ add_procs_to_declared_vtab (derived, vtype); diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c index bfd8b01..b8f0b02 100644 --- a/gcc/fortran/module.c +++ b/gcc/fortran/module.c @@ -82,7 +82,7 @@ along with GCC; see the file COPYING3. If not see /* Don't put any single quote (') in MOD_VERSION, if yout want it to be recognized. */ -#define MOD_VERSION "9" +#define MOD_VERSION "10" /* Structure that describes a position within a module file. */