This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Leaking bitmap data in ree.c?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]