This is the mail archive of the
gcc@gcc.gnu.org
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: Sat, 2 Apr 2016 20:58:06 -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> <20160321171530 dot GA27540 at ball> <56F02BA3 dot 3090600 at redhat dot com> <20160403004957 dot GD10837 at ball>
On Sat, Apr 02, 2016 at 08:49:57PM -0400, Trevor Saunders wrote:
> On Mon, Mar 21, 2016 at 11:13:07AM -0600, Jeff Law wrote:
> > On 03/21/2016 11:15 AM, Trevor Saunders wrote:
> > >
> > >>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.
> > Can't hurt.
>
> ok, finally got around to that. The git mirror now has branches
> tbsaunde/bitmap tbsaunde/bitmap2 and tbsaunde/bitvec. I think the first
> two actually aren't very valuable, trying add a ctor / dtor to
> bitmap_head itself seems like a poor idea bound to run into some strange
> use of bitmaps. It seems a lot safer to add a auto_bitmap and move
> things over to it. On the other hand the bitvec branch is trying to
> build something sbitmap like, but trying to use vec to manage the
> storage instead of doing it manually. I'm not sure why I didn't finish that
> idea.
oh, and now I do remember why, it looks like it depends on making vec
call destructors when objects in the vector are removed which makes
sense, but it makes implementing pop () tricky.
Trev
>
> Trev
>
> >
> > FWIW, bitmaps are low level and independent of trees, rtl, etc that we ought
> > to (in theory) be able to class-ify them and build a real unit testing
> > framework for them.
> >
> > jeff