On Mon, Mar 21, 2016 at 9:32 PM, Jeff Law <l...@redhat.com> 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
