From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98911 invoked by alias); 27 Nov 2015 08:36:15 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 98897 invoked by uid 89); 27 Nov 2015 08:36:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vk0-f51.google.com Received: from mail-vk0-f51.google.com (HELO mail-vk0-f51.google.com) (209.85.213.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 27 Nov 2015 08:36:13 +0000 Received: by vkbs1 with SMTP id s1so65109036vkb.1 for ; Fri, 27 Nov 2015 00:36:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.31.56.18 with SMTP id f18mr38686235vka.19.1448613370790; Fri, 27 Nov 2015 00:36:10 -0800 (PST) Received: by 10.103.45.207 with HTTP; Fri, 27 Nov 2015 00:36:10 -0800 (PST) In-Reply-To: <56581453.7090601@suse.cz> References: <565774DC.5020808@suse.cz> <56581453.7090601@suse.cz> Date: Fri, 27 Nov 2015 08:45:00 -0000 Message-ID: Subject: Re: [PATCH 7/N] Fix newly introduced memory leak in tree-ssa-loop-ivopts.c From: "Bin.Cheng" To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: gcc-patches List , Bin Cheng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg03313.txt.bz2 On Fri, Nov 27, 2015 at 4:29 PM, Martin Li=C5=A1ka wrote: > On 11/27/2015 04:54 AM, Bin.Cheng wrote: >> On Fri, Nov 27, 2015 at 5:08 AM, Martin Li=C5=A1ka wrot= e: >>> Hi. >>> >>> There's one more patch that fixes really of lot memory leaks related to= loop >>> ivopts. >>> The regression was introduced by r230647. >>> >>> Patch was tested in the series with the rest and the compiler bootstraps >>> successfully. >>> >>> Ready for trunk? >> >> Hi Martin, >> Thanks for fixing my issue. The IVO part of patch is OK. >> Just for me to understand, iv_common_cand is freed via free_ptr_hash, >> and thus typed_free_remove. So what leaks is the iv_use * vector in >> struct iv_common_cand, right? I did forget to free that. > > Hi. > > You are right, the suggested patch uses delete operator for deallocation = of iv_common_cand > structure. That eventually calls dtor of auto_vec. > >> BTW, how do you monitor memory use in GCC, maybe I can run same test >> for my future patches. > > I've been working on removal of memory leaks using valgrind, just configu= re the compiler with > '--enable-valgrind-annotations' and run for instance: > > valgrind --leak-check=3Dyes --trace-children=3Dyes ./gcc/xgcc -Bgcc ../gc= c/testsuite/gcc.dg/tree-ssa/loop-32.c -c -O2 > > Producing: > ... > =3D=3D13919=3D=3D 216 bytes in 3 blocks are definitely lost in loss recor= d 679 of 795 > =3D=3D13919=3D=3D at 0x4C2A00F: malloc (in /usr/lib64/valgrind/vgprelo= ad_memcheck-amd64-linux.so) > =3D=3D13919=3D=3D by 0x107CEDF: xrealloc (xmalloc.c:178) > =3D=3D13919=3D=3D by 0xAC46AA: reserve (vec.h:288) > =3D=3D13919=3D=3D by 0xAC46AA: reserve (vec.h:1406) > =3D=3D13919=3D=3D by 0xAC46AA: reserve_exact (vec.h:1426) > =3D=3D13919=3D=3D by 0xAC46AA: create (vec.h:1441) > =3D=3D13919=3D=3D by 0xAC46AA: record_common_cand(ivopts_data*, tree_n= ode*, tree_node*, iv_use*) (tree-ssa-loop-ivopts.c:3133) > =3D=3D13919=3D=3D by 0xAC49C5: add_iv_candidate_for_use(ivopts_data*, = iv_use*) (tree-ssa-loop-ivopts.c:3220) > =3D=3D13919=3D=3D by 0xAC4EA2: add_iv_candidate_for_uses (tree-ssa-loo= p-ivopts.c:3294) > =3D=3D13919=3D=3D by 0xAC4EA2: find_iv_candidates(ivopts_data*) (tree-= ssa-loop-ivopts.c:5705) > =3D=3D13919=3D=3D by 0xAC839D: tree_ssa_iv_optimize_loop (tree-ssa-loo= p-ivopts.c:7708) > =3D=3D13919=3D=3D by 0xAC839D: tree_ssa_iv_optimize() (tree-ssa-loop-i= vopts.c:7758) > =3D=3D13919=3D=3D by 0xADE4D0: (anonymous namespace)::pass_iv_optimize= ::execute(function*) (tree-ssa-loop.c:520) > =3D=3D13919=3D=3D by 0x920033: execute_one_pass(opt_pass*) (passes.c:2= 335) > =3D=3D13919=3D=3D by 0x920547: execute_pass_list_1(opt_pass*) [clone .= constprop.84] (passes.c:2408) > =3D=3D13919=3D=3D by 0x920559: execute_pass_list_1(opt_pass*) [clone .= constprop.84] (passes.c:2409) > =3D=3D13919=3D=3D by 0x920559: execute_pass_list_1(opt_pass*) [clone .= constprop.84] (passes.c:2409) > =3D=3D13919=3D=3D by 0x9205A4: execute_pass_list(function*, opt_pass*)= (passes.c:2419) > ... Thanks for explanation, I will do that in future. Thanks, bin