Re: Leaking bitmap data in ree.c?

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Mar 21, 2016 at 6:19 PM, Jeff Law <law@redhat.com> 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:
>> https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02371.html
>
> 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...

Richard.

> jeff