From patchwork Mon Dec 31 12:40:13 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 208852 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 E74042C00A8 for ; Mon, 31 Dec 2012 23:40:31 +1100 (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=1357562433; h=Comment: DomainKey-Signature:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=MhyB1tA kT47qct37hpq0VjXJiBY=; b=odglROPib4OjSEclCqlGJKrQO0ThR3QsXsaeayJ YG7IzHQ4cm+whMX8ojOQxICoIXYTy12deAzleFklTl4Hv/KKiVQgEkIm8x/pHMUr jDddLljCXOA+8MiaRVu+GVflPCK30kUoMGXbY27HO6i1O25AYcMe03f5aeoBKJSc +ESk= 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:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=uqsUy2aAevUnZWwpiUUV+uP2bBjBTn5Xh7cWm9ryNEF8P62BJKzjl+HCgUH3z6 7tACKX7fcOJR/X6M2V87I4DUtrSkYtYfKwxiyCLR7WkT9KakXI7OT8YRYTpfn6K4 8hIVmxh99nryktwD0ksC2ngRkhWf8mZvojfC0iYWSPrzA=; Received: (qmail 22622 invoked by alias); 31 Dec 2012 12:40:20 -0000 Received: (qmail 22605 invoked by uid 22791); 31 Dec 2012 12:40:18 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Dec 2012 12:40:15 +0000 Received: from archimedes.net-b.de (port-92-195-100-21.dynamic.qsc.de [92.195.100.21]) by mx01.qsc.de (Postfix) with ESMTP id 9766D3CB0D; Mon, 31 Dec 2012 13:40:13 +0100 (CET) Message-ID: <50E187AD.9010501@net-b.de> Date: Mon, 31 Dec 2012 13:40:13 +0100 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: gcc patches , gfortran Subject: Patch, Fortran] FINAL (prep patches 5/5): Activate the generation of the finalization wrapper 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 (Patch 4/5, which adds support for noncontiguous arrays to the finalization wrapper follows soon; it works, but I should do a small cleanup before submittal.) Contrary to the other patches in this series, this patch changes the generated code - and it changes the ABI. With this patch, the virtual table (vtab) gets a "_final" components between _copy and the user's type-bound procedures. Additionally, the finalization wrapper is generated. Note: This patch only adds the finalization wrapper function - it does not use it. Thus, there is no user-visible benefit of this patch - except for the avoided 4.9 ABI issue. The risk of this patch is rather low (only ICEs are possible). The (only? main?) advantage of this patch is that it avoids ABI breakage for polymorphic variables immediately after branching 4.8. (Due to two recent patches, we have already broken the ABI for 4.8 and bumped the .mod version. Thus, this breakage could make use of the already bumped .mod file version number.) Build and regtested on x86-64-gnu-linux. OK for the 4.8 trunk? – Alternatively: OK for the 4.9 trunk? * * * The next step is make use of the finalization wrapper for both calling the user's finalization subroutines but also for deallocating allocatable components of polymorphic variables/components. ("polymorphic freeing"). At https://userpage.physik.fu-berlin.de/~tburnus/final/ I have a draft patch which handles some of the cases; however, the support is incomplete and there are possibly some issues. One could consider supporting some subset of polymorphic freeing or finalization using the user's FINAL subroutines even for 4.8. However, it looks more like GCC 4.9 material. Comments? Tobias 2012-12-31 Tobias Burnus * class.c (gfc_find_derived_vtab): Activate the generation of the finalization wrapper. diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 61d65e7..84f383e 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -2024,9 +2425,7 @@ gfc_find_derived_vtab (gfc_symbol *derived) components and the calls to finalization subroutines. Note: The actual wrapper function can only be generated at resolution time. */ - /* FIXME: Enable ABI-breaking "_final" generation. */ - if (0) - { + if (gfc_add_component (vtype, "_final", &c) == FAILURE) goto cleanup; c->attr.proc_pointer = 1; @@ -2034,7 +2433,6 @@ gfc_find_derived_vtab (gfc_symbol *derived) c->tb = XCNEW (gfc_typebound_proc); c->tb->ppc = 1; generate_finalization_wrapper (derived, ns, tname, c); - } /* Add procedure pointers for type-bound procedures. */ if (!derived->attr.unlimited_polymorphic)