http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #51 from rguenther at suse dot de <rguenther at suse dot de> 2012-08-16 14:06:06 UTC --- On Thu, 16 Aug 2012, stevenb.gcc at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 > > --- Comment #50 from stevenb.gcc at gmail dot com <stevenb.gcc at gmail dot > com> 2012-08-16 13:55:40 UTC --- > On Thu, Aug 16, 2012 at 2:10 PM, rguenth at gcc dot gnu.org > <gcc-bugzi...@gcc.gnu.org> wrote: > > bitmap stats are confusing because they show leaks for bitmaps we free > > by releasing their obstack. DF and PTA bitmaps are largest. > > The bitmap obstack stats are not very reliable anyway, I think. I've > been using my own stats for this (with a size_t version of > obstack_memory_used: > > +static size_t > +obstack_memory_used2 (struct obstack *h) > +{ > + struct _obstack_chunk* lp; > + size_t nbytes = 0; > + > + for (lp = h->chunk; lp != 0; lp = lp->prev) > + { > + nbytes += (size_t) (lp->limit - (char *) lp); > + } > + return nbytes; > +} > + > > so that also the "freed" bitmap elements are counted). With that, you > can show that the reg_obstack and bitmap_default_obstack grow up to > several GB that isn't released between passes. An added problem is Hum, I thought we release those obstacks after each pass ...
