From patchwork Tue Aug 21 22:26:21 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 179183 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 844DA2C00BC for ; Wed, 22 Aug 2012 08:26:51 +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=1346192814; 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=SNs1UuZ IApU3Pz2T5TB3X+NUbX4=; b=S25lcZhHD5BpHR2rFm55EwnqnHWcVNNbQeV9A9T RONdf5u5zdutUidC33TkjNySiNZUAO/QZgJARxoGki1VMxEMIuqsP24Gc6M2BoDh QOafLP/zqOylU0uSTOFaFT3MwEIoQhBWFEfeR7v+Mp7K5mA6L3WwjvBxH1cEdnSP hwlU= 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=jSdVyDsu49Ai9O5qA/+LjP5rC5D1D1HFFT7qTvv6ed4Ny42T/Vdp5DUPHTlnhM evqssCiLRASOzP2amxfr6ZocC9twEfHBWZx4sefofUWTCYH+9StL1xqc7VjlpcxW Lxvd3bcR7U1wxqhkARGYkOf4xKNcK+9AFxoYsmA+35/cg=; Received: (qmail 26445 invoked by alias); 21 Aug 2012 22:26:41 -0000 Received: (qmail 26382 invoked by uid 22791); 21 Aug 2012 22:26:39 -0000 X-SWARE-Spam-Status: No, hits=-1.8 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; Tue, 21 Aug 2012 22:26:25 +0000 Received: from [192.168.178.22] (port-92-204-67-8.dynamic.qsc.de [92.204.67.8]) by mx01.qsc.de (Postfix) with ESMTP id B3A593D31A; Wed, 22 Aug 2012 00:26:22 +0200 (CEST) Message-ID: <50340B0D.4080406@net-b.de> Date: Wed, 22 Aug 2012 00:26:21 +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 Subject: [Patch, Fortran, committed] free gfc_code of EXEC_END_PROCEDURE 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 Background: There is currently a memory leakage cleanup in the middle end – and fixing PR 54332 would probably have been also easier without FE leaks. I think we should join in an try to remove some leakage - and try to not introduce new ones. * * * Committed: For EXPR_END_PROCEDURE, I have committed one fix as obvious (-> parse.c). However, I have a test case where parse_contained still leaks memory, possibly another, similar patch is needed in addition. * * * There are also plenty of leaks related to the freeing of gfc_ss. I attached a draft patch (trans-expr.c, trans-intrinsics.c), which is probably okay, but not yet regtested. OK with a changelog (and if it regtested)? Note: The patch is incomplete, e.g. "argss" of gfc_conv_procedure_call is not (or not always) freed. Ditto for rss of gfc_trans_assignment_1; ditto for lss and rss of gfc_trans_pointer_assignment * * * * * * * * * * * * Additionally, there is a memory leak when generating more than one procedure per TU: The memory which is allocated but not freed gfc_generate_function_code -> (generate_coarray_init or trans_function_start) -> init_function_start -> prepare_function_start -> init_emit The memory should be feed via (backend_init_target or lang_dependent_init_target) -> expand_dummy_function_end -> free_after_compilation The latter seems to operate on "cfun" – hence, it only frees the last "cfun" and not all. However, despite some longer debugging (e.g. using a main program, which calls create_main_function), I failed to find the problem. * * * And module.c can also leak plenty of memory ... Tobias diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index 4f7d026..cfb0862 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -533,6 +533,7 @@ gfc_copy_class_to_class (tree from, tree to, tree nelems) loop.to[0] = nelems; gfc_trans_scalarizing_loops (&loop, &loopbody); gfc_add_block_to_block (&body, &loop.pre); + gfc_cleanup_loop (&loop); tmp = gfc_finish_block (&body); } else @@ -6770,6 +6771,7 @@ gfc_trans_arrayfunc_assign (gfc_expr * expr1, gfc_expr * expr2) if (!expr2->value.function.isym) { realloc_lhs_loop_for_fcn_call (&se, &expr1->where, &ss, &loop); + gfc_cleanup_loop (&loop); ss->is_alloc_lhs = 1; } else @@ -6778,6 +6780,7 @@ gfc_trans_arrayfunc_assign (gfc_expr * expr1, gfc_expr * expr2) gfc_conv_function_expr (&se, expr2); gfc_add_block_to_block (&se.pre, &se.post); + gfc_free_ss (se.ss); return gfc_finish_block (&se.pre); } diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index fac29c7..d0aebe9 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -1328,6 +1328,7 @@ gfc_conv_intrinsic_rank (gfc_se *se, gfc_expr *expr) argse.descriptor_only = 1; gfc_conv_expr_descriptor (&argse, expr->value.function.actual->expr, ss); + gfc_free_ss (ss); gfc_add_block_to_block (&se->pre, &argse.pre); gfc_add_block_to_block (&se->post, &argse.post);