From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101803 invoked by alias); 22 Mar 2016 09:37:35 -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 101783 invoked by uid 89); 22 Mar 2016 09:37:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1856, disallow X-HELO: mail-wm0-f45.google.com Received: from mail-wm0-f45.google.com (HELO mail-wm0-f45.google.com) (74.125.82.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 22 Mar 2016 09:37:33 +0000 Received: by mail-wm0-f45.google.com with SMTP id p65so154624342wmp.0 for ; Tue, 22 Mar 2016 02:37:32 -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; bh=tlYSWBhKywmIoANi3l0udM0Eem74v72/1xYeFxAstE0=; b=VlLljYsJdyxSyy3OgVO+Z29l7oCH2TREAxj2slWeNdzBb+ZDj9m6lE0c+/W+G7cOlp 4aMG3YIp7NSv5RT8SIOU0mJJeeoZOKhWnvZQp0ONNYU9CPUB53rbKTcqPPJ23aIp9ijs 3ancUn3uHVy6F4W2gmLkBnSQCLHBKXvEO5QzcdpTaTOx99NFXfXxCymPEtRRzG4ucNx+ RX0dJAXlGeU3m8fh2UBicgVaA40YSq3Vj8mSK3jdKU4hFkZi8W7P+5iO3ep3PQm3YZYA rrbZ64jsJdaLfysPZF64SYtAYpGGNym7Kr5hLtmlySSMiFhPfr8o6erZJ7a2TQzq9YO4 K9hQ== X-Gm-Message-State: AD7BkJIlIaLt0hGQWft2VlnupVP1liokYrxdKHEP53PeOIHERHlr3/BNx/w2fKpHeEzTMJG5VpqyGpf6V32bPA== MIME-Version: 1.0 X-Received: by 10.195.17.200 with SMTP id gg8mr7830242wjd.72.1458639450123; Tue, 22 Mar 2016 02:37:30 -0700 (PDT) Received: by 10.194.121.132 with HTTP; Tue, 22 Mar 2016 02:37:30 -0700 (PDT) In-Reply-To: <56F05A74.2080200@redhat.com> References: <56F0461C.3070601@redhat.com> <56F0470F.6080804@redhat.com> <56F05A74.2080200@redhat.com> Date: Tue, 22 Mar 2016 10:22:00 -0000 Message-ID: Subject: Re: [RFA][PATCH] Adding missing calls to bitmap_clear From: Richard Biener To: Jeff Law Cc: Bernd Schmidt , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg01233.txt.bz2 On Mon, Mar 21, 2016 at 9:32 PM, Jeff Law wrote: > On 03/21/2016 01:10 PM, Bernd Schmidt wrote: >> >> On 03/21/2016 08:06 PM, Jeff Law wrote: >>> >>> >>> As noted last week, find_removable_extensions initializes several >>> bitmaps, but doesn't clear them. >>> >>> This is not strictly a leak as the GC system should find dead data, but >>> it's better to go ahead and clear the bitmaps. That releases the >>> elements back to the cache and presumably makes things easier for the GC >>> system as well. >>> >>> Bootstrapped and regression tested on x86_64-linux-gnu. >>> >>> OK for the trunk? >> >> >> Looks like they don't leak anywhere, so ok. Probably ok even to install >> it now but maybe stage1 would be better timing. > > I don't mind waiting for the next stage1, this is a pretty minor issue. It's ok at this stage as it will also fix -fmem-report. Please also move the thing back to heap, see below. Btw we should disallow bitmap_initialize (&x, NULL) as it does not do the same thing as BITMAP_ALLOC (NULL), it does the same thing as BITMAP_ALLOC_GC (). Thus I'd rather have a bitmap_initialize_gc (&x) and a bitmap_initialize (&x, NULL) that ends up using the global bitmap obstack. No idea where REE came from history wise. A grep shows only ira.c: bitmap_initialize (&seen_insns, NULL); ree.c: bitmap_initialize (&init, NULL); ree.c: bitmap_initialize (&kill, NULL); ree.c: bitmap_initialize (&gen, NULL); ree.c: bitmap_initialize (&tmp, NULL); btw, so please consider simply changing bitmap_initialize behavior. The IRA use also should use the global bitmap obstack as users around that use use BITMAP_ALLOC (NULL). [use a default arg for 'obstack' if possible, you have to verify it works with/without --enable-gather-detailed-mem-stats] Thanks, Richard. > jeff