On Fri, Nov 15, 2013 at 12:11:07PM +0100, Richard Biener wrote: > On Fri, Nov 15, 2013 at 11:37 AM, Trevor Saunders <tsaund...@mozilla.com> > wrote: > > On Fri, Nov 15, 2013 at 10:56:24AM +0100, Richard Biener wrote: > >> On Thu, Nov 14, 2013 at 10:33 PM, Jeff Law <l...@redhat.com> wrote: > >> > On 11/14/13 14:14, Richard Biener wrote: > >> >>> > >> >>> > >> >>> I'm just pointed out that of all the stuff you changed, these were the > >> >>> only ones I saw where lifetimes were changed significantly. > >> >> > >> >> > >> >> I still ask why we need a new type and cannot put this functionality > >> >> into > >> >> bitmap_head itself. > >> > > >> > Given that bitmap is just a *bitmap_head_def aren't we suggesting the > >> > same > >> > thing? > >> > >> Not sure - I thought Trevor wanted to make auto_bitmap a full C++ thing, > >> not bitmap itself? > > > > My only firm goals are less manual memory management, and moving the > > bitmap_head bit onto the stack would be really nice. I'd also like to > > leave bitmaps allocated in gc memory alone for the time being, but those > > are the only firm goals. I'm currently trying the approach of adding > > constructors and destructors to bitmap_head, but apparently something is > > causing them to get invoked even when everybody deals with bitmap_head * > > which leads to ICEs that I'm investigating now. > > They are used embedded into other structures as well (to avoid a > pointer indirection).
yeah, I see that now, but actually what seems to haave een causing the problem is that df-core.c df-problems.c and tree-ssa-pre.c where already putting them directly on the stack. That and the fact bitmap_clear doesn't make head->first NULL, and so calling bitmap_clear twice on the same bitmap causes a double free. Trev > > Richard. > > > Trev > > > >> > >> Richard. > >> > >> > jeff