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

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

[kito.cheng at gmail dot com]

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

Kito Cheng <kito.cheng at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kito.cheng at gmail dot com

--- Comment #3 from Kito Cheng <kito.cheng at gmail dot com> ---
still ice for riscv64 and arm after
r10-7074-g191bcd0f30dd37dec773efb0125afdcae9bd90ef

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

[nathan at gcc dot gnu.org]

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

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-03-12
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |nathan at gcc dot gnu.org

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

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
I cannot reproduce this with the cross or native compilers I've tried:
native: x86_64-linux, aarch64-linux
cross: arm-eabi riscv64-unknown-linux

The cross compilers are hosted on x86_64-linux

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

[kito.cheng at gmail dot com]

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

--- Comment #5 from Kito Cheng <kito.cheng at gmail dot com> ---
Hi Nathan:

Double confirmed again, it still ICE to me, but I might miss some info so I
post my env and configure option:

GCC: g:b73f69020f08208d2d969fcf8879bd294a6e3596

Host: x86_64-linux (Ubuntu 18.04)
Target: arm-eabi
Configure option: --target=arm-eabi --enable-languages=c,c++

Bootstrap gcc only
$ arm-eabi-g++
../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/g++.dg/cpp0x/variadic-sizeof4.C
-std=c++14


reduced cc1plus command:
$
/scratch1/kitoc/riscv-gnu-workspace/pr94044/arm-eabi/install/bin/../libexec/gcc/arm-eabi/10.0.1/cc1plus
-quiet 
../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/testsuite/g++.dg/cpp0x/variadic-sizeof4.C
-quiet -mcpu=arm7tdmi -marm -march=armv4t -std=c++14  -o -

debug info:
#6  0x00000000008abd8b in comptypes (t1=0x7ffff6964f18, t2=<optimized out>,
strict=<optimized out>)
    at ../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cp/typeck.c:1489
1489      gcc_checking_assert (TREE_CODE (t1) != TYPE_ARGUMENT_PACK
(gdb) call debug_tree(t1)
 <type_argument_pack 0x7ffff6964f18
    type <tree_vec 0x7ffff69681e0 length:2
...


Let me know if it still can't reproduce...thanks :)

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

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Still no luck.

I'm at cb99630f254 2020-03-11 | fold undefined pointer offsetting
Configured with 
../../src/configure '--with-mpfr=/data/users/nathans/tools'
'--with-mpc=/data/users/nathans/tools' '--enable-checking=yes'
--disable-multilib --disable-bootstrap '--enable-languages=c,c++,lto'
'--target=arm-eabi'


devvm2772+2:5>./cc1plus -quiet  variadic-sizeof4.C -quiet -mcpu=arm7tdmi -marm
-march=armv4t -std=c++14 -o -
... assembly emitted ...

I'm using a fresh binutils cross toolchain

I understand where the compiler got to from your traceback.  I don't understand
what constructed the trees that got it there!

[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]

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.

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

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So perhaps to ease reproduction, tweak the hash function in this case to always
return 0?

[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]

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

--- Comment #9 from Jim Wilson <wilson at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> So perhaps to ease reproduction, tweak the hash function in this case to
> always return 0?

Yes, that works.  I just didn't have a chance to look at the hash function last
night.  With the hash function hacked I can reproduce for any target and any
-std=c++X value.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 789ccdb..4337928 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1733,7 +1733,8 @@ hash_tmpl_and_args (tree tmpl, tree args)
 hashval_t
 spec_hasher::hash (spec_entry *e)
 {
-  return hash_tmpl_and_args (e->tmpl, e->args);
+  return 0;
+  //  return hash_tmpl_and_args (e->tmpl, e->args);
 }

 /* Recursively calculate a hash value for a template argument ARG, for use

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

[nathan at gcc dot gnu.org]

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

--- Comment #10 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Thanks for poking at this Jim!

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathan Sidwell <nathan@gcc.gnu.org>:

https://gcc.gnu.org/g:26b3e568a60e9fd851efb436531752a5e49e6419

commit r10-7330-g26b3e568a60e9fd851efb436531752a5e49e6419
Author: Nathan Sidwell <nathan@acm.org>
Date:   Mon Mar 23 03:39:49 2020 -0700

    [PR94044] Fix ICE with sizeof<argumentpack>

    Thanks to Jim for figuring out how to reproduce the problem, I was
    able to apply pr94044-jig.diff to poorly hash the specialization
    table. (That places all the specializations of a particular template
    in the same bucket, forcing us to compare the arguments.)

    The testcase creates sizeof_exprs containing argument packs, and we
    can no longer use same_type_p on those.

            PR c++/94044
            * tree.c (cp_tree_equal) [SIZEOF_EXPR]: Detect argument pack
            operand.

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

[nathan at gcc dot gnu.org]

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

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Fixed 26b3e568a60e9fd851efb436531752a5e49e6419