From patchwork Mon May 9 10:57:42 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 619827 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3r3K9X27Nlz9s9G for ; Mon, 9 May 2016 20:58:04 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=KVs15IRj; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; q=dns; s= default; b=WkIfF4ypluhssbkryp5kVo7HhTQ7nDR7Iv8dgdB0lqXEqlw1+7xWv KcAR5Q7laZ1i9PzVOl3aYrkRwzWmmdMVRNG6ycKtoNCJ+q9vAQweshRvBFU9ZNOz ZfnNVUstwdghHqgU4ZMH7Tjx4qgy8O6OPR09fZ9HbWuWTkxhF5ARac= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; s=default; bh=y2MqkazbIMgCYm/Rw1huwv1rylk=; b=KVs15IRjNoMqjeWD+rKJe53QnHwx vpmmwae0KEBaw+t3T2FxfjExgILWVo+a01oIYVeiwpCyZ0bu0kYBTClIokhREant g9WvJPltR5T6iVOjHFzmxUakNcf5sk1SfRTksMqFQxuygmo2v4Oyx6PddOyY9001 P2et09uO3JyPta4= Received: (qmail 5621 invoked by alias); 9 May 2016 10:57:56 -0000 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 Received: (qmail 5607 invoked by uid 89); 9 May 2016 10:57:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=sk:actual_, leak, clique X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 09 May 2016 10:57:45 +0000 Received: by mail-wm0-f48.google.com with SMTP id a17so179885298wme.0 for ; Mon, 09 May 2016 03:57:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=IKL3uduR0LkIjCwBZmOAQwY0JsCpxOSvZ2KOS/N1pMM=; b=X9vsVLl1MuaAUbxJZG1m4eXyKPNlK7ofbdpg8LlJ/lJ8pT7r6vWrac17cJSHE+liVF lHrsPcce4wWEjEBBLm3YK4kB+uDBxf/0ubjiyBaJxVRrznBEqmlrwLnGxL0UlPmyedHm yPxQkEYJZyMeWr/3SSUR5tMaURpcuYsRd7mTOJ5aCA/zvcf65ymmoaWTtSkkJ4yjWM6N eDB4UiHlodEpH4dTveMKo+6NZLF3mxAoswl+US+CW9sifRnteQYxJ74yUjlqyFPnDMR4 UL2fIy2we3VXA2T9aVm/om4DvDgmRGPLP/GnRGYtVH5utUzxEK+qtfKxnKqCFOgmjI0h sRcA== X-Gm-Message-State: AOPr4FU4l47XNxp+nHx1/DiFjSKJZ5D5gN7GaDzNyWL5DBnv8gS0XqRWQnGpoW19nRJ3B0ri1WfOz2kjJ7B+dQ== MIME-Version: 1.0 X-Received: by 10.28.52.75 with SMTP id b72mr10393882wma.98.1462791462416; Mon, 09 May 2016 03:57:42 -0700 (PDT) Received: by 10.194.113.102 with HTTP; Mon, 9 May 2016 03:57:42 -0700 (PDT) In-Reply-To: <572C8F82.6000604@suse.cz> References: <572C6DA9.9080807@suse.cz> <572C8F82.6000604@suse.cz> Date: Mon, 9 May 2016 12:57:42 +0200 Message-ID: Subject: Re: [PATCH] Fix memory leak in tree-inliner From: Richard Biener To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: GCC Patches , Jan Hubicka X-IsSubscribed: yes On Fri, May 6, 2016 at 2:35 PM, Martin Liška wrote: > On 05/06/2016 12:56 PM, Richard Biener wrote: >> Hmmm. But this means debug stmt remapping calls >> remap_dependence_clique which may end up bumping >> cfun->last_clique and thus may change code generation. >> >> So what debug stmts contain MEM_REFs? If you put an assert >> processing_debug_stmt == 0 in >> remap_dependence_clique I'd like to see a testcase that triggers it. >> >> Richard. > > Ok, I've placed the suggested assert which is triggered for following debug statement: > > (gdb) p debug_gimple_stmt(stmt) > # DEBUG D#21 => a_1(D)->dim[0].ubound > > (gdb) p debug_tree(*tp) > type size > unit size > align 64 symtab -160828560 alias set -1 canonical type 0x7ffff6a4f000 > fields > unsigned DI file /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90 line 21 col 0 > size > unit size > align 64 offset_align 128 > offset > bit offset context chain > > pointer_to_this reference_to_this chain > > > arg 0 type > public unsigned restrict DI size unit size > align 64 symtab 0 alias set -1 canonical type 0x7ffff6a53150> > var def_stmt GIMPLE_NOP > > version 1> > arg 1 constant 0>> > > for the following test-case: > gfortran /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90 -O3 -g Ok. I suggest you instead do sth like does that resolve the issue? If so, this is ok for trunk and branches. Thanks, Richard. > Martin > > > Index: gcc/tree-inline.c =================================================================== --- gcc/tree-inline.c (revision 236021) +++ gcc/tree-inline.c (working copy) @@ -840,7 +840,7 @@ is_parm (tree decl) static unsigned short remap_dependence_clique (copy_body_data *id, unsigned short clique) { - if (clique == 0) + if (clique == 0 || processing_debug_stmt) return 0; if (!id->dependence_map) id->dependence_map = new hash_map;