On 5/19/20 11:38 PM, Patrick Palka via Gcc-patches wrote:
After enabling sanitization of the specialization tables, we are
triggering one of the hash table sanity checks in the below testcase.
The reason is that when looking up the specialization j<int> in the
type_specializations table, the sanity check finds that the existing
entry j<n<t>::m> compares equal to j<int> but hashes differently.
The discrepancy is due to structural_comptypes looking through
TYPENAME_TYPEs (via resolve_typename_type), something which
iterative_hash_template_arg doesn't do. So the TYPENAME_TYPE n<t>::m is
considered equal to int, but the hashes of these template arguments are
different.
It seems wrong for the result of a specialization table lookup to depend
on the current scope, so this patch makes structural_comptypes avoid
calling resolve_typename_type when comparing_specializations.
In order for the below testcase to deterministically trigger the
sanitization error without this patch, we also need to fix the location
of the call to hash_table::verify within hash_table::find_with_hash.
Yes please! I have this problem on the modules branch, but didn't
notice I can press comparing_specializations into service, so added a
module-specific global just there.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?
gcc/ChangeLog:
PR c++/95223
* hash-table.h (hash_table::find_with_hash): Move up the call to
hash_table::verify.
gcc/cp/ChangeLog:
PR c++/95223
* gcc/cp/typeck.c (structural_comptypes): Don't perform
context-dependent resolution of TYPENAME_TYPEs when
comparing_specializations.
ok.
nathan
--
Nathan Sidwell
