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: adding destroyable objects into Ggc

On Fri, Oct 21, 2011 at 10:56 PM, Basile Starynkevitch
<> wrote:
> On Fri, 21 Oct 2011 10:43:29 +0200
> Richard Guenther <> 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.


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