On 04/13/2016 11:54 AM, Nathan Sidwell wrote:
This patch builds from Jason's proto-patch in comment #26. As Jason
discovered, that led to link problems with gt_ggc_mx (tree_node *&) when
building cc1. Making 'hash_map<tree,fundef_copy *>' GC-able caused
gengtype to put the GC-walkers for tree into constexpr.c. No idea why.
That's also what led me to add the user GTY stuff in the patch I posted
earlier. For some reason manual GC fns kept the tree GC-walker in a sane
place. I wonder if the same problem is why Patrick's original patch
wrapped the hash_map pointer in a local structure?
Rather than peer into gengtype's mind, I figured on changing to use a
regular tree->tree mapper, which didn't disturb gengtype. I employ a
TREE_LIST to hold the bits that fundef_copy held (body, parms, result)
on (PURPOSE, VALUE, TYPE). A little unclean, but not the first time
non-types are on such a TYPE, IIRC. While there I noticed that the
getter only needed to use a hash getter, rather than get_or_insert.
The thrust of the patch makes the fundef copies and constexpr call
tables GCable, not GC-deletable. Thus their contents are not affected by
GC occurrences. Finally, a new hook called at end of parsing to delete
the constexpr call & fundef copies tables, so they don't remain after
parsing. We don't do anything about stopping them getting too big.
Patch survives boot & test, and fixes the testcase in 70594/#4 (without
Jakub's patch to not emit UIDs in the gimple dump).
ok?
The fini_constexpr stuff is OK immediately.
The rest of the patch is OK if Jakub thinks it should go in, but if his
approach addresses the problem, we might as well continue to GC the tables.
Jason
