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: whereis PLUGIN_REGISTER_GGC_CACHES? how to migrate it for GCC v6.x?

Hi David,

Thanks for your kind response!

在 2017年07月11日 21:25, David Malcolm 写道:
On Tue, 2017-07-11 at 10:50 +0800, Leslie Zhai wrote:
在 2017年07月10日 22:16, David Malcolm 写道:
On Sat, 2017-07-08 at 15:50 +0800, Leslie Zhai wrote:
Hi GCC developers,

There was


pseudo-events for register_callback in GCC v4.x, but how to
for GCC v6.x? there is no  PLUGIN_REGISTER_GGC_CACHES deprecated
ChangeLog-201X nor git log plugin.h... please give me some hint,
a lot!
Trevor [CCed] removed it 2014-12-10 in r218558
(eb06b2519a361b7784b1807115fcb3dea0226035) in the commit:
"remove gengtype support for param_is use_param, if_marked and
tree allocators"

The patch was here:

where he talks about plugin migration.
   Some plugins may need to add extra GGC root tables, e.g. to handle
their own
   @code{GTY}-ed data. This can be done with the
   pseudo-event with a null callback and the extra root table (of type
-ggc_root_tab*}) as @code{user_data}.  Plugins that want to use the
-@code{if_marked} hash table option can add the extra GGC cache
-by @code{gengtype} using the @code{PLUGIN_REGISTER_GGC_CACHES}
pseudo-event with
-a null callback and the extra cache table (of type @code{struct
-as @code{user_data}.  Running the @code{gengtype -p @var{source-dir}
-@var{file-list} @var{plugin*.c} ...} utility generates these extra
+ggc_root_tab*}) as @code{user_data}.  Running the
+ @code{gengtype -p @var{source-dir} @var{file-list} @var{plugin*.c}
+utility generates these extra root tables.

After diff gcc-6.3.0/gcc/testsuite/gcc.dg/plugin and
then migrate to GCC v6.x like this:

// Register our garbage collector roots.
#if GCC_MAJOR < 6
    register_callback(plugin_name, PLUGIN_REGISTER_GGC_CACHES, NULL,
    register_callback(plugin_name, PLUGIN_REGISTER_GGC_ROOTS, NULL,

and Trevor talks more about GTY((if_marked(XXX), param_is(XXX)))
migrate to GTY((cache)) hash_table<MyHasher> such as:

#if (GCC_MAJOR < 6)
// FIXME: gengtype not support macro?
static GTY((if_marked("tree2int_marked_p"), param_is(struct
      htab_t intCache;
struct intCacheHasher : ggc_cache_ptr_hash<tree2int> {
    static inline hashval_t hash(tree2int *t2i) {
      return tree_map_base_hash(&t2i->base);

    static inline bool equal(tree2int *a, tree2int *b) {
      return a->base.from == b->base.from;
static GTY((cache))
      hash_table<intCacheHasher> *intCache;

But I have no idea why gengtype does not support macro? it just ignored #if
(GCC_MAJOR < 6) still parse GTY((if_marked(XXX), param_is(XXX)))
but not GTY((cache)) hash_table<MyHasher>... please give me some
thanks a lot!
Unfortunately, gengtype is not a full parser for all of C++; IIRC it
doesn't have any real support for the preprocessor.

Maybe you can work around it in your plugin by providing two different
headers, one for GCC_MAJOR < 6, the other for >= 6, and setting up the
build so that gengtype is invoked on the correct header.  (I know this
is ugly, sorry).

Alternatively, maybe there's another way to solve this by rethinking
the data structure.  It seems like you have a hash table of some kind.
  Does the hash table "own" references to other GC-managed entities, or
is it simply referenced *by* other GC-managed entities.  Maybe there's
I am migrating dragonegg to GCC v6.3 and LLVM v3.9, at first it needs to be built successfully, no warning is better :) but I only migrated part of it, for example: Caching values in GCC trees right now and the relationship might be: GTY((cache)) hash_table<intCacheHasher> *intCache <- Cache::setCachedInteger <- TypeConversion::set_decl_index... When I finished the migration, with the whole view, then I need to rethink the data structure as you suggested.

PS: Trevor's email is not available? thanks!

another way to represent this data which would sidestep the issue.  (I
don't know, I'm just speculating).

Hope this is helpful

Leslie Zhai - a LLVM developer

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