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?