This is the mail archive of the
mailing list for the GCC project.
Re: Leaking bitmap data in ree.c?
- From: Trevor Saunders <tbsaunde at tbsaunde dot org>
- To: Jeff Law <law at redhat dot com>
- Cc: "gcc at gnu dot org" <gcc at gnu dot org>
- Date: Mon, 21 Mar 2016 13:15:30 -0400
- Subject: Re: Leaking bitmap data in ree.c?
- Authentication-results: sourceware.org; auth=none
- References: <56EC5478 dot 5080500 at redhat dot com> <20160321032339 dot GA24419 at ball> <56F0246A dot 5000002 at redhat dot com>
On Mon, Mar 21, 2016 at 10:42:18AM -0600, Jeff Law wrote:
> On 03/20/2016 09:24 PM, Trevor Saunders wrote:
> >On Fri, Mar 18, 2016 at 01:18:16PM -0600, Jeff Law wrote:
> >>Is it just me, or does find_removable_extensions leak bitmap data for INIT,
> >>KILL, GEN and TMP?
> >>It calls bitmap_initialize on all of them, but never clears the bitmaps...
> >>Am I missing something?
> >See this lovely comment for bitmap_initialize_stat () which is macroed
> >to bitmap_initialize ()
> >/* Initialize a bitmap header. OBSTACK indicates the bitmap obstack
> > to allocate from, NULL for GC'd bitmap. */
> >So I think the elements for those bitmaps are just getting allocated on
> >the gc heap, and everything is correct though of course it would be nice
> >to stop using the gc there.
> Yea, but it's kindof silly to force the ggc system to handle this. At the
> least a bitmap_clear would return the bitmap elements to the bitmap element
> cache (which should also be more efficient for the ggc system)
> I'll resist the urge for now to apply RAII principles in this code, but
> that'd probably a much cleaner way to think about the problem in general.
I worked on a couple attempts to c++ify bitmaps a while back, but never
finished any of them, but I could probably publish what I did in case
someone wants to pick that up for gcc 7.