On 11/20/19 7:21 PM, Jakub Jelinek wrote:
On Mon, Nov 18, 2019 at 02:41:48PM -0500, Jason Merrill wrote:
2019-11-11 Jakub Jelinek <ja...@redhat.com>
PR c++/92458
* constraint.cc: Include tree-hash-traits.h.
(decl_tree_cache_traits): New type.
(decl_tree_cache_map): New typedef.
(decl_constraints): Change type to decl_tree_cache_map *
from tree_cache_map *.
Do we need to change other tree_cache_map uses, too? It looks like many of
them map from decls.
I guess it depends on whether those hash tables can have data in them across
PCH save/restore.
As an experiment, I've built stdc++.h.gch with -std=c++2a and put a
breakpoint in c_common_read_pch after gt_pch_restore.
Besides decl_constraints I've changed, I see also defarg_inst table with
data on it, which means that defarg_inst lookups after PCH read might not
find saved instantiations in the table.
So, defarg_inst might be another candidate for decl_tree_cache_map,
especially because PARM_DECLs are the keys in it.
All the other C++ FE tree_cache_map hash tables are empty, so no idea if it
is needed or not.
If decl_tree_cache_map will be needed in more than one spot, I'll probably
need to move it to some generic header.
Most of them probably need it, for code that uses the relevant features.
Except debug_type_map, which probably needs to use TYPE_UID.
Or we might make default_hash_traits<tree> use DECL_UID for decls and
TYPE_UID for types even if it doesn't do the more complex analysis of
tree_operand_hash.
Jason