$ cat testcase.C template<int __v> struct integral_constant { static const int value = __v; }; template<bool, class> struct enable_if; template<bool _Bp, class _Tp> using __enable_if_t = enable_if<_Bp, _Tp>; template<class...> using void_t = void; template<class... _Pred> void_t<__enable_if_t<_Pred::value, void>...> foo(); using type = decltype(foo<integral_constant<1>>()); $ cat testcase.C | g++ --param=hash-table-verification-limit=1000 -x c++ - hash table checking failed: equal operator returns true for a pair of values with a different hash value <stdin>: In substitution of ‘template<class ...> using void_t = void [with <template-parameter-1-1> = {__enable_if_t<_Pred::value, void>...}]’: <stdin>:5:71: required by substitution of ‘template<class ... _Pred> void_t<enable_if<_Pred::value, void>...> foo() [with _Pred = {integral_constant<1>}]’ <stdin>:6:48: required from here <stdin>:5:71: internal compiler error: in hashtab_chk_error, at hash-table.c:137
Started with r11-7931
While reducing the modules bug 99479, I found that this might be a GC issue.
*** Bug 99861 has been marked as a duplicate of this bug. ***
*** Bug 100002 has been marked as a duplicate of this bug. ***
I think I found something similar on openttd-12.1. Seems to be a mostly gcc-12 regression: $ cat bug.cpp template <typename T> using t = T; template <typename...> struct s; template <typename... Args> s<t<Args>...> f() { f<void>(); } $ g++-12.0.0 --param=hash-table-verification-limit=1000 -O1 -o a.o -c bug.cpp hash table checking failed: equal operator returns true for a pair of values with a different hash value bug.cpp: In substitution of 'template<class ... Args> s<Args ...> f() [with Args = {void}]': bug.cpp:3:56: required from here bug.cpp:3:43: internal compiler error: in hashtab_chk_error, at hash-table.c:137 3 | template <typename... Args> s<t<Args>...> f() { f<void>(); } | ^ 0x9c316d hashtab_chk_error() ../../gcc-12-20220102/gcc/hash-table.c:137 0xbeca15 hash_table<spec_hasher, false, xcallocator>::verify(spec_entry* const&, unsigned int) ../../gcc-12-20220102/gcc/hash-table.h:1036 0xbecb6f hash_table<spec_hasher, false, xcallocator>::find_with_hash(spec_entry* const&, unsigned int) ../../gcc-12-20220102/gcc/hash-table.h:921 0xbd58bc lookup_template_class_1 ../../gcc-12-20220102/gcc/cp/pt.c:9905 0xbd7e06 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../gcc-12-20220102/gcc/cp/pt.c:10260 0xbd7e06 tsubst_aggr_type ../../gcc-12-20220102/gcc/cp/pt.c:13642 0xbcdf6a tsubst_function_type ../../gcc-12-20220102/gcc/cp/pt.c:15154 0xbbffcd tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc-12-20220102/gcc/cp/pt.c:15970 0xbe40f9 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) ../../gcc-12-20220102/gcc/cp/pt.c:21857 0x9e1529 add_template_candidate_real ../../gcc-12-20220102/gcc/cp/call.c:3544 0x9e2473 add_template_candidate ../../gcc-12-20220102/gcc/cp/call.c:3632 0x9e2473 add_candidates ../../gcc-12-20220102/gcc/cp/call.c:6165 0x9e8849 add_candidates ../../gcc-12-20220102/gcc/cp/call.c:4692 0x9e8849 perform_overload_resolution ../../gcc-12-20220102/gcc/cp/call.c:4709 0x9ed682 build_new_function_call(tree_node*, vec<tree_node*, va_gc, vl_embed>**, int) ../../gcc-12-20220102/gcc/cp/call.c:4816 0xc03d31 finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, bool, bool, int) ../../gcc-12-20220102/gcc/cp/semantics.c:2865 0xb64f91 cp_parser_postfix_expression ../../gcc-12-20220102/gcc/cp/parser.c:7821 0xb4d49a cp_parser_binary_expression ../../gcc-12-20220102/gcc/cp/parser.c:9984 0xb4dfbe cp_parser_assignment_expression ../../gcc-12-20220102/gcc/cp/parser.c:10288 0xb4fae9 cp_parser_expression ../../gcc-12-20220102/gcc/cp/parser.c:10458 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ g++-12.0.0 -v Using built-in specs. COLLECT_GCC=/nix/store/9s988q1yj67hk7d2v7wxl961h2d34mgg-gcc-debug-12.0.0/bin/g++ COLLECT_LTO_WRAPPER=/nix/store/9s988q1yj67hk7d2v7wxl961h2d34mgg-gcc-debug-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20220102 (experimental) (GCC)
Trying to understand what the error means: Crash happens when we look up entry in gcc/cp/pt.c:static GTY (()) spec_hash_table *type_specializations; It's a hash table of entries of spec_entry type: struct GTY((for_user)) spec_entry { tree tmpl; /* The general template this is a specialization of. */ tree args; /* The args for this (maybe-partial) specialization. */ tree spec; /* The specialization itself. */ }; spec_hasher type defines both hasher and equality. hash is defined on fields 'tmpl' and 'args', equality is defined on 'tmpl', 'args' and sometimes 'spec': bool spec_hasher::equal (spec_entry *e1, spec_entry *e2) { int equal; ++comparing_specializations; ++comparing_dependent_aliases; ++processing_template_decl; equal = (e1->tmpl == e2->tmpl && comp_template_args (e1->args, e2->args)); if (equal && flag_concepts /* tmpl could be a FIELD_DECL for a capture pack. */ && TREE_CODE (e1->tmpl) == TEMPLATE_DECL && VAR_P (DECL_TEMPLATE_RESULT (e1->tmpl)) && uses_template_parms (e1->args)) { /* Partial specializations of a variable template can be distinguished by constraints. */ tree c1 = e1->spec ? get_constraints (e1->spec) : NULL_TREE; tree c2 = e2->spec ? get_constraints (e2->spec) : NULL_TREE; equal = equivalent_constraints (c1, c2); } --processing_template_decl; --comparing_dependent_aliases; --comparing_specializations; return equal; } static hashval_t hash_tmpl_and_args (tree tmpl, tree args) { hashval_t val = iterative_hash_object (DECL_UID (tmpl), 0); return iterative_hash_template_arg (args, val); } hashval_t spec_hasher::hash (spec_entry *e) { return hash_tmpl_and_args (e->tmpl, e->args); } How can hash differ when values match?
With: diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 0fa4a162354..9a8bfa51049 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -45,6 +45,7 @@ along with GCC; see the file COPYING3. If not see #include "gcc-rich-location.h" #include "selftest.h" #include "target.h" +#include "print-tree.h" /* The type of functions taking a tree, and some additional data, and returning an int. */ @@ -9902,6 +9903,9 @@ lookup_template_class_1 (tree d1, tree arglist, tree in_decl, tree context, elt.args = arglist; elt.spec = NULL_TREE; hash = spec_hasher::hash (&elt); + debug_tree (arglist); + fprintf (stderr, "hashing %p, %p: %d\n", arglist, gen_tmpl, hash); + entry = type_specializations->find_with_hash (&elt, hash); if (entry) I see: ./xg++ -B. --param=hash-table-verification-limit=10000 -O1 ~/Programming/testcases/pr103769.C -c <tree_vec 0x7ffff77059e0 length:1 elt:0 <template_type_parm 0x7ffff770e348 Args VOID align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff770ed20 index 0 level 1 orig_level 1 chain <type_decl 0x7ffff75d4ab0 Args>>> hashing 0x7ffff77059e0, 0x7ffff7722000: -913564281 <tree_vec 0x7ffff7705b00 length:1 elt:0 <type_argument_pack 0x7ffff770e5e8 type <tree_vec 0x7ffff7705b20 length:1 elt:0 <type_pack_expansion 0x7ffff770e540>> VOID align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff770e5e8>> hashing 0x7ffff7705b00, 0x7ffff7722080: -1965388615 <tree_vec 0x7ffff7705ce0 length:1 elt:0 <type_argument_pack 0x7ffff77280a8 type <tree_vec 0x7ffff7705d00 length:1 elt:0 <type_pack_expansion 0x7ffff770e498>> VOID align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff77280a8>> hashing 0x7ffff7705ce0, 0x7ffff7722080: 683150001 verification fails for: (gdb) p **entry $2 = { tmpl = <template_decl 0x7ffff7722080 s>, args = <tree_vec 0x7ffff7705b00>, spec = <record_type 0x7ffff770e690 s> } (gdb) p *comparable $3 = { tmpl = <template_decl 0x7ffff7722080 s>, args = <tree_vec 0x7ffff7705ce0>, spec = <tree 0x0> } So as seen, comp_template_args (e1->args, e2->args)) return true, while the hash values are different at the place where I dump them.
Slightly simpler executable example without recursion: template <typename T> using t = T; template <typename...> struct s {}; template <typename...Args> s<t<Args>...> f() { return {};} int main() { f<void>(); }
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:07be8f8da4c6840a1fd6b2229b147e50cc6f03dc commit r12-7848-g07be8f8da4c6840a1fd6b2229b147e50cc6f03dc Author: Jason Merrill <jason@redhat.com> Date: Fri Mar 25 11:26:06 2022 -0400 c++: ICE with alias in pack expansion [PR103769] This was breaking because when we stripped the 't' typedef in s<t<Args>...> to be s<Args...>, the TYPE_MAIN_VARIANT of "Args..." was still "t<Args>...", because type pack expansions are treated as types. Fixed by using the right function to copy a "type". PR c++/99445 PR c++/103769 gcc/cp/ChangeLog: * tree.cc (strip_typedefs): Use build_distinct_type_copy. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias5.C: New test.
The releases/gcc-11 branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:3bf2e1bfc9858516e028137b313e4c689b0c8cd4 commit r11-9707-g3bf2e1bfc9858516e028137b313e4c689b0c8cd4 Author: Jason Merrill <jason@redhat.com> Date: Fri Mar 25 11:26:06 2022 -0400 c++: ICE with alias in pack expansion [PR103769] This was breaking because when we stripped the 't' typedef in s<t<Args>...> to be s<Args...>, the TYPE_MAIN_VARIANT of "Args..." was still "t<Args>...", because type pack expansions are treated as types. Fixed by using the right function to copy a "type". PR c++/99445 PR c++/103769 gcc/cp/ChangeLog: * tree.c (strip_typedefs): Use build_distinct_type_copy. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias5.C: New test.
Fixed.
Great! Just to recall: At the URL https://lelyakin.de/hashtab/ You can always find results of everyday testing how can last version of GCC compile standard c++ headers. And sorry, it cannot compile all of them does not matter in which order.
*** Bug 102739 has been marked as a duplicate of this bug. ***