This is the mail archive of the 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 Mon, Mar 21, 2016 at 6:19 PM, Jeff Law <> wrote:
> On 03/21/2016 11:16 AM, David Malcolm wrote:
>> On Mon, 2016-03-21 at 11:13 -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.
>>> 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.
>> Something like:
> Like that, or complete instantiation outside GCC.

I don't like more C++-ification just for the sake of it.  Like the alloc-pool
C++ification caused more issues than it fixed.

I'd happily approve sth like an auto_bitmap class though (bah, we can't
have auto <X> as auto is already taken!).

Notice that using bitmap_initialize is a micro-optimization to avoid one
indirection.  I doubt it matters for REE.

Also keep in mind bitmap statistics - leaving bitmaps to GC only like
REE seems to do will mess them up.  Bitmaps that have used
bitmap_initialize and allocating from GC need to call bitmap_clear
on them.  In fact REE should simply use &bitmap_default_obstack,
I think that it uses GC is an oversight...


> jeff

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