This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HÃÃMÃÃÃÃtxÃtsÃ
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 27 Jan 2012 08:52:28 +0000
- Subject: [Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HÃÃMÃÃÃÃtxÃtsÃ
- Auto-submitted: auto-generated
- References: <bug-51852-4@http.gcc.gnu.org/bugzilla/>
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).