[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Nathan Sidwell --- patch applied
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #12 from Nathan Sidwell --- Author: nathan Date: Mon Apr 10 11:25:44 2017 New Revision: 246802 URL: https://gcc.gnu.org/viewcvs?rev=246802=gcc=rev Log: PR target/79905 * config/rs6000/rs6000.c (rs6000_vector_type): New. (rs6000_init_builtins): Use it. PR target/79905 * g++.dg/torture/pr79905.C: New. Added: trunk/gcc/testsuite/g++.dg/torture/pr79905.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org --- Comment #11 from Nathan Sidwell --- I'll take a look. Before I forget, I noticed that the canonical type hasher gets given a bespoke hash code by the type creator. I think the aim is to avoid a generic hasher. This leads to various interesting ways the hash is generated. The attribute variant creator contains a generic hasher anyway. I have patches on the c++-modules branch to canonicalize this hashing.
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 Bill Schmidt changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #10 from Bill Schmidt --- 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 constant 32> unit size constant 4> align 32 symtab 0 alias set -1 canonical type 0x3fffb5b10738 precision 32 min max pointer_to_this > (gdb) bt #0 dependent_type_p (type=0x3fffb5b10738) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23486 #1 0x104c7220 in dependent_type_p_r (type=0x3fffb5d33fa8) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23366 #2 0x104c7c10 in dependent_type_p (type=0x3fffb5d33fa8) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23485 #3 0x104c71c0 in dependent_type_p_r (type=0x3fffb5d34050) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23360 #4 0x104c7c10 in dependent_type_p (type=0x3fffb5d34050) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23485 #5 0x1046fa5c in uses_template_parms (t=0x3fffb5d34050) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:9351 #6 0x106d0b3c in build_cplus_array_type (elt_type=0x3fffb5d34050, index_type=0x0) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/tree.c:899 #7 0x103db958 in cxx_init_decl_processing () at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/decl.c:4154 #8 0x1057c22c in cxx_init () at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/lex.c:250 #9 0x1119a5a8 in lang_dependent_init ( name=0x3bb8 "pr79905.cpp") at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:1763 #10 0x1119ae7c in do_compile () at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:1986 #11 0x1119b448 in toplev::main (this=0x3316, argc=24, argv=0x3738) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:2134 #12 0x11f2f160 in main (argc=24, argv=0x3738) 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.
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #9 from Bill Schmidt --- I believe the problem has to do with the basic integer type for SI mode changing hash values after it is first created. I stopped in make_vector_type for all vectors created with 4 elements, and found three of them with a base type having SI mode. The first two had the same base integer type, reported as "int public SI". Both were canonicalized to the first one that was created, all good. The third had the same base integer type, but that type had changed slightly in the meanwhile. It was now reported as "int public type_6 SI". As a result, this appeared to change the hash for vector types based upon it. This third type was created in response to the "vector int b;" decl (the AltiVec decl); and the hash of this type was now unique, so it was canonicalized to itself. Interestingly, the V4i type was created without ever going through the make_vector_type interface. I haven't tracked down where it came from, but I believe that to be irrelevant. When we ICE, the V4i type exists, is based on the same "int public type_6 SI" type, and canonicalizes to the AltiVec type. So the problem is not that the AltiVec and V4i types are incompatible. We ICE when observing that the very first type created is not canonicalized to the same type as the V4i type is. My theory is that the change involving "type_6" is responsible for this.
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #8 from Bill Schmidt --- But hm, build_vector_type calls make_vector_type which canonicalizes using type_hash_canon, so this seems ok. Perhaps the problem is with the V4i type?
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #7 from Bill Schmidt --- In rs6000.c: rs6000_handle_altivec_attribute(), the altivec(vector__) attribute is used to assign V4SI_type_node as the associated type in this case. V4SI_type_node has a canonical type field that points to itself. This type is created in rs6000_init_builtins() as follows: V4SI_type_node = build_vector_type (intSI_type_node, 4); My guess is that we need to call some interface that will look for an existing type and canonicalize to that one, but I don't know how any of this front-endish stuff works. I'll keep looking.
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #6 from Michael Meissner --- On Thu, Mar 16, 2017 at 03:10:19PM +, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 Generally, the "vector" keyword is a conditional macro that looks at the next token or two to decide whether or not to expand the macro. If the next token is one of the standard types or __bool/__pixel, then __vector/vector is expanded to: __attribute__((altivec(vector__)) The magic is in rs6000-c.c, particularly in altivec_categorize_keyword, init_vector_keywords, rs6000_macro_to_expand, and rs6000_cpu_cpp_builtins.
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #5 from Richard Biener --- The frontend should have assigned the same TYPE_CANONICAL here. I don't know much about the vector keyword magic we have on ppc.
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 Bill Schmidt changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Bill Schmidt --- CCing Richard. Do you have an opinion about my question in c#3?
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #3 from Bill Schmidt --- So, is the desired behavior that the front end produce an error message instead? Or is the front end supposed to unify these two types and accept the code?
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905
Pat Haugen changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- Comment #2 from Pat Haugen ---
Reduced testcase.
pthaugen@pike:~/temp/creduce$ cat junk.cpp
typedef int V4i __attribute__((vector_size(16)));
void a(V4i ) {
vector int b;
a(b);
}
pthaugen@pike:~/temp/creduce$ ~/install/gcc/trunk/bin/g++ -S junk.cpp
junk.cpp: In function ‘void a(V4i)’:
junk.cpp:4:6: internal compiler error: canonical types differ for identical
types __vector(4) int and V4i {aka __vector(4) int}
a(b);
^
0x1038318b comptypes(tree_node*, tree_node*, int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/cp/typeck.c:1433
0x1019524f standard_conversion
/home/pthaugen/src/gcc/trunk/gcc/gcc/cp/call.c:1187
0x101a6af3 implicit_conversion
/home/pthaugen/src/gcc/trunk/gcc/gcc/cp/call.c:1839
...
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-06 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed with a cross compiler.
