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)
yeah > 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. Trev > > jeff
