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.
