On Fri, Oct 21, 2011 at 10:56 PM, Basile Starynkevitch
<bas...@starynkevitch.net> wrote:
> On Fri, 21 Oct 2011 10:43:29 +0200
> Richard Guenther <richard.guent...@gmail.com> wrote:
>> So there is no inherent limitation with the GGC machinery.
>
> There are at least some annoyances:
>
> If a C++ class is GTY-ed, or is pointed by a field inside a GTY-ed struct,
> and if
> that class contains for example a PPL data (or simply if a GTY-ed struct
> contains a PPL
> data) we need to have the PPL destuctor invoked when Ggc release the struct.
Same as in C. If you have a pointer to malloc() memory in a GTY-ed
struct it will leak.
Which is why in the GTY world there is a dont-do-that rule, instead
you need to put
your malloc memory in GC space, too.
Thus, not a C++ limitation, but a general issue with mixing GC and
non-GC things.
Now complicated things more and make the malloc region point to GC memory again
and you'll see why generally mixing GC/non-GC things isn't the very best idea.
> To be more specific, if you want to associate trees with PPL coefficients (in
> a way
> visible to several passes, so using Ggc), you will declare in C
>
> struct GTY (()) treewithcoef_st {
> tree tr;
> ppl_Coefficient_t co;
> };
>
> it will leak, because <ppl_c.h> requires that when the field co is no more
> useful, it
> should be released with
> ppl_delete_Coefficient (p->co);
> [since actually ppl_Coefficient_t is an opaque non null pointer to some C++
> class of PPL]
Don't do that then.
Richard.
