[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

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

--- Comment #10 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
For C++, "type_6" indicates that TYPE_DEPENDENT_P_VALID is nonzero for the
type.  This apparently gets set for the basic SI type during C++
language-dependent initialization, but only after the first two V4SI types are
created.  Here's the backtrace when this occurs:

Breakpoint 8, dependent_type_p (type=0x3fffb5b10738)
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23486
23486         TYPE_DEPENDENT_P_VALID (type) = 1;
(gdb) ptr type
 <integer_type 0x3fffb5b10738 int public SI
    size <integer_cst 0x3fffb5ad1728 type <integer_type 0x3fffb5b101f8
bitsizetype> constant 32>
    unit size <integer_cst 0x3fffb5ad1740 type <integer_type 0x3fffb5b10150
sizetype> constant 4>
    align 32 symtab 0 alias set -1 canonical type 0x3fffb5b10738 precision 32
min <integer_cst 0x3fffb5ad16e0 -2147483648> max <integer_cst 0x3fffb5ad16f8
2147483647>
    pointer_to_this <pointer_type 0x3fffb5b11a40>>
(gdb) bt
#0  dependent_type_p (type=0x3fffb5b10738)
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23486
#1  0x00000000104c7220 in dependent_type_p_r (type=0x3fffb5d33fa8)
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23366
#2  0x00000000104c7c10 in dependent_type_p (type=0x3fffb5d33fa8)
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23485
#3  0x00000000104c71c0 in dependent_type_p_r (type=0x3fffb5d34050)
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23360
#4  0x00000000104c7c10 in dependent_type_p (type=0x3fffb5d34050)
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23485
#5  0x000000001046fa5c in uses_template_parms (t=0x3fffb5d34050)
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:9351
#6  0x00000000106d0b3c in build_cplus_array_type (elt_type=0x3fffb5d34050, 
    index_type=0x0) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/tree.c:899
#7  0x00000000103db958 in cxx_init_decl_processing ()
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/decl.c:4154
#8  0x000000001057c22c in cxx_init ()
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/lex.c:250
#9  0x000000001119a5a8 in lang_dependent_init (
    name=0x3ffffffffbb8 "pr79905.cpp")
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:1763
#10 0x000000001119ae7c in do_compile ()
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:1986
#11 0x000000001119b448 in toplev::main (this=0x3ffffffff316, argc=24, 
    argv=0x3ffffffff738)
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:2134
#12 0x0000000011f2f160 in main (argc=24, argv=0x3ffffffff738)
    at /home/wschmidt/gcc/gcc-mainline-test2/gcc/main.c:39
(gdb) 

I think we will need a C++ expert to advise what to do about this.  I'm now
officially out of my league.  CCing Jason for advice on who we should ask.