This is the mail archive of the gcc-bugs@gcc.gnu.org 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]

[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HÃÃMÃÃÃÃtxÃtsÃ


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-27 08:52:28 UTC ---
Created attachment 26476
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26476
pointer_map patch

local_specializations isn't GTY(()) marked at all and inserts GC TREE_LIST
nodes
into the hash table that aren't reachable otherwise.

The obvious fix I've tried first:
--- pt.c 2012-01-27 09:28:26.887327122 +0100
+++ pt.c 2012-01-27 09:45:01.787479945 +0100
@@ -79,7 +79,7 @@ static tree cur_stmt_expr;
 /* A map from local variable declarations in the body of the template
    presently being instantiated to the corresponding instantiated
    local variables.  */
-static htab_t local_specializations;
+static GTY ((param_is (union tree_node))) htab_t local_specializations;

 typedef struct GTY(()) spec_entry
 {

for some reason crashed elsewhere.  There is additionally the saving of the
local_specializations pointer, creating a new hash table and destroying +
restoring the pointer afterwards in two places.  Can we ggc_collect () only
when
there is at most one local_specializations array around (i.e. when
saved_local_specializations in whomever created the hash table is NULL)?

And the second question is, are the local specialization trees also reachable
from some other GC root except for local_specializations htab?  If they are
reachable from elsewhere, it would seem to me it would be much cheaper to use a
pointer_map as done in this patch (the testcase works then).


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