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:49:57 -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>
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.
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