https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <ppa...@gcc.gnu.org>: https://gcc.gnu.org/g:610ae2dbbf98a291782cb05c0fb31e056193e5e2 commit r11-522-g610ae2dbbf98a291782cb05c0fb31e056193e5e2 Author: Patrick Palka <ppa...@redhat.com> Date: Wed May 20 09:15:48 2020 -0400 c++: spec_hasher and TYPENAME_TYPE resolution [PR95223] 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 two 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. 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 * typeck.c (structural_comptypes): Don't perform context-dependent resolution of TYPENAME_TYPEs when comparing_specializations. gcc/testsuite/ChangeLog: PR c++/95223 * g++.dg/template/typename23.C: New test.
