[Bug c++/94044] [10 Regression] internal compiler error: in comptypes, at cp/typeck.c:1490 on riscv64-unknown-linux-gnu and arm-eabi

["wilson at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #7 from Jim Wilson <wilson at gcc dot gnu.org> ---
I made an attempt to reproduce this.  I wasn't able to reproduce with an
arm-eabi build.  I was able to reproduce with a riscv64-linux build.  The funny
part is that I was able to build two compilers from the same gcc sources, one
which reproduces and one which does not, which differ only in exactly how I did
the build.  For the failing build, I had a complete riscv-gnu-toolchain build
available when configuring.  For the working build it was just binutils and gcc
without glibc/linux header files, and a top-of-tree binutils version unlike the
first build.

Debugging the two side by side, I see that execution diverges at line 9680 in
cp/pt.c
      entry = type_specializations->find_with_hash (&elt, hash);
The working compiler has no hash hit and returns zero.  The failing compiler
has a hash hit, and then dies inside spec_hasher::equal.

In the spec_hasher::equal function I see

(gdb) print *e1
$29 = {tmpl = <template_decl 0x7ffff5edc300 size>,
  args = <tree_vec 0x7ffff5ec7be0>, spec = <record_type 0x7ffff5ef45e8 size>}
(gdb) print *e2
$30 = {tmpl = <template_decl 0x7ffff5edc300 size>,
  args = <tree_vec 0x7ffff5efb080>, spec = <tree 0x0>}

(gdb) pt
 <tree_vec 0x7ffff5ec7be0 length:1
    elt:0 <sizeof_expr 0x7ffff5ec7ba0
        type <integer_type 0x7ffff5deb7e0 long unsigned int public unsigned
type_6 DI
            size <integer_cst 0x7ffff5dd6ae0 constant 64>
            unit-size <integer_cst 0x7ffff5dd6af8 constant 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff5deb7e0 precision:64 min <integer_cst 0x7ffff5dd6db0 0> max <integer_cst
0x7ffff5dd7620 18446744073709551615>
            pointer_to_this <pointer_type 0x7ffff5df8f18>>
        readonly
        arg:0 <type_argument_pack 0x7ffff5ef4540
            type <tree_vec 0x7ffff5ef3668 length:2 elt:0 <template_type_parm
0x7ffff5ef4000 T> elt:1 <type_pack_expansion 0x7ffff5ef4150>>
            type_0 type_6 VOID
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff5ef4540>
        tmp.C:13:23 start: tmp.C:13:23 finish: tmp.C:13:35>>
(gdb) print e2->args
$32 = <tree_vec 0x7ffff5efb080>
(gdb) pt
 <tree_vec 0x7ffff5efb080 length:1
    elt:0 <sizeof_expr 0x7ffff5efb040
        type <integer_type 0x7ffff5deb7e0 long unsigned int public unsigned
type_6 DI
            size <integer_cst 0x7ffff5dd6ae0 constant 64>
            unit-size <integer_cst 0x7ffff5dd6af8 constant 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff5deb7e0 precision:64 min <integer_cst 0x7ffff5dd6db0 0> max <integer_cst
0x7ffff5dd7620 18446744073709551615>
            pointer_to_this <pointer_type 0x7ffff5df8f18>>
        readonly
        arg:0 <type_argument_pack 0x7ffff5efa2a0
            type <tree_vec 0x7ffff5ef9258 length:2 elt:0 <type_pack_expansion
0x7ffff5ef6dc8> elt:1 <template_type_parm 0x7ffff5ef6f18 T>>
            type_0 type_6 VOID
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff5efa2a0>
        tmp.C:13:23 start: tmp.C:13:23 finish: tmp.C:13:35>>
(gdb) 

It then eventually dies inside comptypes because TREE_CODE (t1) is
type_pack_expansion.  And also TREE_CODE (t2) is type_pack_expansion.  This is
called from the SIZEOF_EXPR case in cp_tree_equal.

If tree addresses are being used for the hash codes, this could just be bad
luck whether it fails or not.