Bug 103769 - [11 Regression] checking ICE in hashtab_chk_error with alias template and pack expansion after r11-7931
Summary: [11 Regression] checking ICE in hashtab_chk_error with alias template and pac...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 12.0
: P2 normal
Target Milestone: 11.3
Assignee: Jason Merrill
URL:
Keywords: ice-checking, ice-on-valid-code
: 99861 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-12-19 16:39 UTC by Patrick Palka
Modified: 2022-03-29 19:02 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 10.3.0, 12.0
Known to fail: 11.2.0
Last reconfirmed: 2021-12-19 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Palka 2021-12-19 16:39:31 UTC
$ 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
Comment 1 Patrick Palka 2021-12-19 16:42:40 UTC
Started with r11-7931
Comment 2 Andrew Pinski 2021-12-30 16:13:55 UTC
While reducing the modules bug 99479, I found that this might be a GC issue.
Comment 3 Andrew Pinski 2021-12-30 16:18:38 UTC
*** Bug 99861 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Pinski 2022-01-01 04:19:08 UTC
*** Bug 100002 has been marked as a duplicate of this bug. ***
Comment 5 Sergei Trofimovich 2022-01-07 08:05:33 UTC
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)
Comment 6 Sergei Trofimovich 2022-01-07 09:09:16 UTC
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?
Comment 7 Martin Liška 2022-01-07 09:27:22 UTC
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.
Comment 8 Sergei Trofimovich 2022-01-08 20:02:44 UTC
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>(); }
Comment 9 CVS Commits 2022-03-28 13:37:08 UTC
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.
Comment 10 CVS Commits 2022-03-28 19:13:14 UTC
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.
Comment 11 Jason Merrill 2022-03-28 19:14:25 UTC
Fixed.
Comment 12 Alexander Lelyakin 2022-03-29 19:02:14 UTC
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.