[RFC PATCH] add auto_bitmap

[Trevor Saunders]

On Fri, Nov 15, 2013 at 12:11:07PM +0100, Richard Biener wrote:
> On Fri, Nov 15, 2013 at 11:37 AM, Trevor Saunders <tsaunders@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 <law@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