Created attachment 35574 [details] Test case (input13.ii): Compile with g++ -std=c++11 -g The bug reminds me of 66103, but is one is without LTO. Compiling the attached code snipped with "g++ -std=c++11 -g" give the following ICE. Without "-g", it doesn't crash: input13.ii:53:34: required from here input13.ii:44:74: error: TYPE_CANONICAL is not compatible template < typename _Tp, typename _Alloc = std::allocator < _Tp > >class vector:protected _Vector_base < _Tp, [...] input13.ii:44:74: internal compiler error: verify_type failed 0xf3e280 verify_type(tree_node const*) ../../gcc/tree.c:13257 0x96dc04 gen_type_die_with_usage ../../gcc/dwarf2out.c:20250 0x96e2a3 gen_type_die_with_usage ../../gcc/dwarf2out.c:20337 0x97f21c gen_type_die ../../gcc/dwarf2out.c:20434 0x97f21c gen_formal_types_die ../../gcc/dwarf2out.c:18027
(In reply to Tobias Burnus from comment #0) > The bug reminds me of bug 66103, but is one is without LTO.
Confirmed.
Works after reverting Honza's r223391.
Seems to be fixed by Honza's patch at https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02225.html / by his commit r223608. Should the test case be test-cased?
Hmm, today, I see it again. I wonder why it (seemed to) work(ed) yesterday.
A bit more reduced: % cat test_66214.ii class A; template <typename = int> class B { typedef A value_type; void m_fn1(const value_type &); }; class A { int m_upperBorder; B<> m_tupelTypes; }; % g++ -c -g test_66214.ii test_66214.ii: In instantiation of ‘class B<>’: test_66214.ii:8:7: required from here test_66214.ii:2:33: error: TYPE_CANONICAL is not compatible
*** Bug 66490 has been marked as a duplicate of this bug. ***
Jaon, the issue here is that TYPE_CANONICAL is incomplete type: <record_type 0x3fff8e94c8d0 A readonly type_5 VOID align 8 symtab 0 alias set -1 canonical type 0x3fff8e94c8d0 context <translation_unit_decl 0x3fff96fc0078 D.1> full-name "const class A" n_parents=0 use_template=0 interface-unknown reference_to_this <reference_type 0x3fff8e94ca20>> while the type itself is complete (it is a completetion of the class A provided later): <record_type 0x3fff8e94d158 value_type readonly used type_5 VOID align 8 symtab -1903885616 alias set -1 canonical type 0x3fff8e94c8d0 fields <field_decl 0x3fff8e834c00 m_upperBorder type <integer_type 0x3fff8e770690 int public type_6 SI size <integer_cst 0x3fff8e7316b0 constant 32> unit size <integer_cst 0x3fff8e7316c8 constant 4> align 32 symtab 0 alias set -1 canonical type 0x3fff8e770690 precision 32 min <integer_cst 0x3fff8e731668 -2147483648> max <integer_cst 0x3fff8e731680 2147483647> pointer_to_this <pointer_type 0x3fff8e7717a0>> private decl_3 VOID file t.C line 7 col 7 align 1 offset_align 1 context <record_type 0x3fff8e94c4e0 A> chain <type_decl 0x3fff8e834b68 A type <record_type 0x3fff8e94ceb8 A> nonlocal decl_4 VOID file t.C line 6 col 9 align 1 context <record_type 0x3fff8e94c4e0 A> result <record_type 0x3fff8e94c4e0 A> >> context <translation_unit_decl 0x3fff96fc0078 D.1> full-name "const value_type" n_parents=0 use_template=0 interface-unknown reference_to_this <reference_type 0x3fff8e94d200>> Shouldn't the canonical type be always the complete variant of the type?
Jason, any news on this: (In reply to Jan Hubicka from comment #8) > Jaon, the issue here is that TYPE_CANONICAL is incomplete type: [...] > Shouldn't the canonical type be always the complete variant of the type?
I have just encountered this problem and reduced a large input file to this: $ cat z.cpp struct A { typedef A B; int m; struct { V(B); } } $ g++ --version|head -1 g++ (GCC) 6.0.0 20150801 (experimental) That provokes the same ICE with this command: $ g++ -g -fpermissive z.cpp z.cpp:5:8: warning: ISO C++ forbids declaration of ‘V’ with no type [-fpermissive] V(B); ^ z.cpp:4:10: error: TYPE_CANONICAL is not compatible struct { ^ <record_type 0x7f3208e9e1f8 A type_5 VOID align 8 symtab 148250704 alias set -1 canonical type 0x7f3208e9e1f8 fields <field_decl 0x7f3208e9b558 m type <integer_type 0x7f3208d3c7e0 int asm_written public SI size <integer_cst 0x7f3208d5a0a8 constant 32> unit size <integer_cst 0x7f3208d5a0c0 constant 4> align 32 symtab 148250944 alias set -1 canonical type 0x7f3208d3c7e0 precision 32 min <integer_cst 0x7f3208d5a060 -2147483648> max <integer_cst 0x7f3208d5a078 2147483647> pointer_to_this <pointer_type 0x7f3208d5e930>> decl_3 VOID file z.cpp line 3 col 7 align 1 offset_align 1 context <record_type 0x7f3208e9e1f8 A> chain <type_decl 0x7f3208e9b428 A type <record_type 0x7f3208e9e2a0 A> used nonlocal decl_4 VOID file z.cpp line 1 col 10 align 1 context <record_type 0x7f3208e9e1f8 A> result <record_type 0x7f3208e9e1f8 A> chain <type_decl 0x7f3208e9b4c0 B>>> context <translation_unit_decl 0x7f32107ca1e0 D.1> full-name "struct A" n_parents=0 use_template=0 interface-unknown chain <type_decl 0x7f3208e9b390 A>> <record_type 0x7f3208e9e348 B type_5 VOID align 8 symtab 0 alias set -1 canonical type 0x7f3208e9e1f8 fields <type_decl 0x7f3208e9b428 A type <record_type 0x7f3208e9e2a0 A type_5 VOID align 8 symtab 0 alias set -1 canonical type 0x7f3208e9e1f8 context <translation_unit_decl 0x7f32107ca1e0 D.1> full-name "struct A" n_parents=0 use_template=0 interface-unknown chain <type_decl 0x7f3208e9b390 A>> used nonlocal decl_4 VOID file z.cpp line 1 col 10 align 1 context <record_type 0x7f3208e9e1f8 A> result <record_type 0x7f3208e9e1f8 A type_5 VOID align 8 symtab 148250704 alias set -1 canonical type 0x7f3208e9e1f8 fields <field_decl 0x7f3208e9b558 m> context <translation_unit_decl 0x7f32107ca1e0 D.1> full-name "struct A" n_parents=0 use_template=0 interface-unknown chain <type_decl 0x7f3208e9b390 A>> chain <type_decl 0x7f3208e9b4c0 B type <record_type 0x7f3208e9e348 B> used nonlocal VOID file z.cpp line 2 col 13 align 1 context <record_type 0x7f3208e9e1f8 A> result <record_type 0x7f3208e9e1f8 A> chain <type_decl 0x7f3208e9b688 ._0>>> context <translation_unit_decl 0x7f32107ca1e0 D.1> full-name "A::B" n_parents=0 use_template=0 interface-unknown chain <type_decl 0x7f3208e9b390 A>> z.cpp:4:10: internal compiler error: verify_type failed 0xfe0959 verify_type(tree_node const*) ../../gcc/tree.c:13570 0x965ed4 gen_type_die_with_usage ../../gcc/dwarf2out.c:20685 0x967506 gen_type_die ../../gcc/dwarf2out.c:20879 0x96837c modified_type_die ../../gcc/dwarf2out.c:10810 0x968b84 add_type_attribute ../../gcc/dwarf2out.c:17486 0x968db7 gen_formal_parameter_die ../../gcc/dwarf2out.c:18100 0x9692c1 gen_formal_types_die ../../gcc/dwarf2out.c:18198 0x960ab7 gen_subprogram_die ../../gcc/dwarf2out.c:19083 0x96483b gen_decl_die ../../gcc/dwarf2out.c:21442 0x963b54 gen_member_die ../../gcc/dwarf2out.c:20377 0x963b54 gen_struct_or_union_type_die ../../gcc/dwarf2out.c:20461 0x963b54 gen_tagged_type_die ../../gcc/dwarf2out.c:20662 0x9669bd gen_type_die_with_usage ../../gcc/dwarf2out.c:20824 0x967506 gen_type_die ../../gcc/dwarf2out.c:20879 0x964bbe gen_decl_die ../../gcc/dwarf2out.c:21465 0x965794 dwarf2out_decl ../../gcc/dwarf2out.c:21915 0x965a6b dwarf2out_type_decl ../../gcc/dwarf2out.c:21625 0xc8446f rest_of_type_compilation(tree_node*, int) ../../gcc/passes.c:336 0x698ef3 finish_struct_1(tree_node*) ../../gcc/cp/class.c:6738 0x69a5a4 finish_struct(tree_node*, tree_node*) ../../gcc/cp/class.c:6904 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. [Exit 1]
Another test case is the GIT version of LLVM, which fails when compiling ExecutionEngine.cpp for Debug+Asserts build.
I hit this when building MariaDB. Reduced testcase: typedef struct bn_gencb_st BN_GENCB; struct bn_gencb_st { void *arg; union { int (*cb_2)(int, int, BN_GENCB *); }; }; g++ -O0 -g -c testcase.i testcase.i:5:15: error: TYPE_CANONICAL is not compatible union { ^ <record_type 0x3fff76fbc630 bn_gencb_st type_5 VOID align 8 symtab 1995243680 alias set -1 canonical type 0x3fff76fbc630 fields <field_decl 0x3fff76eb49a0 arg type <pointer_type 0x3fff76e01110 type <void_type 0x3fff76e00fc0 void> public unsigned DI size <integer_cst 0x3fff76db1470 constant 64> unit size <integer_cst 0x3fff76db1488 constant 8> align 64 symtab 0 alias set -1 canonical type 0x3fff76e01110 pointer_to_this <pointer_type 0x3fff76e04cc8>> decl_3 VOID file testcase.i line 4 col 15 align 1 offset_align 1 context <record_type 0x3fff76fbc630 bn_gencb_st> chain <type_decl 0x3fff76eb4908 bn_gencb_st type <record_type 0x3fff76fbc8d0 bn_gencb_st> nonlocal decl_4 VOID file testcase.i line 3 col 20 align 1 context <record_type 0x3fff76fbc630 bn_gencb_st> result <record_type 0x3fff76fbc630 bn_gencb_st> chain <type_decl 0x3fff76eb4ad0 ._0>>> context <translation_unit_decl 0x3fff79680078 D.1> full-name "struct bn_gencb_st" n_parents=0 use_template=0 interface-unknown pointer_to_this <pointer_type 0x3fff76fbcb70> chain <type_decl 0x3fff76eb47d8 bn_gencb_st>> <record_type 0x3fff76fbc6d8 BN_GENCB type_5 VOID align 8 symtab 1995243600 alias set -1 canonical type 0x3fff76fbc630 context <translation_unit_decl 0x3fff79680078 D.1> full-name "BN_GENCB" n_parents=0 use_template=0 interface-unknown pointer_to_this <pointer_type 0x3fff76fbcac8> chain <type_decl 0x3fff76eb47d8 bn_gencb_st>> testcase.i:5:15: internal compiler error: verify_type failed 0x10dd6617 verify_type(tree_node const*) ../../gcc/gcc/tree.c:13570 0x1067fc67 gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20685 0x10680887 gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20783 0x10681d97 gen_type_die ../../gcc/gcc/dwarf2out.c:20879 0x1067f3d3 gen_formal_types_die ../../gcc/gcc/dwarf2out.c:18225 0x1067f91b gen_subroutine_type_die ../../gcc/gcc/dwarf2out.c:20505 0x1068046f gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20812 0x10680887 gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20783 0x10681d97 gen_type_die ../../gcc/gcc/dwarf2out.c:20879 0x1067538f gen_decl_die ../../gcc/gcc/dwarf2out.c:21519 0x106786bb gen_member_die ../../gcc/gcc/dwarf2out.c:20356 0x106786bb gen_struct_or_union_type_die ../../gcc/gcc/dwarf2out.c:20461 0x106786bb gen_tagged_type_die ../../gcc/gcc/dwarf2out.c:20662 0x1068079f gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20824 0x10681d97 gen_type_die ../../gcc/gcc/dwarf2out.c:20879 0x10675b9b gen_decl_die ../../gcc/gcc/dwarf2out.c:21465 0x1067681f dwarf2out_decl ../../gcc/gcc/dwarf2out.c:21915 0x10676c77 dwarf2out_type_decl ../../gcc/gcc/dwarf2out.c:21625 0x1098065f rest_of_type_compilation(tree_node*, int) ../../gcc/gcc/passes.c:336 0x102c2223 finish_struct_1(tree_node*) ../../gcc/gcc/cp/class.c:6747
*** Bug 67387 has been marked as a duplicate of this bug. ***
*** Bug 67641 has been marked as a duplicate of this bug. ***
Created attachment 36533 [details] Simpler test case - z3.ii Even simpler test case. Compile with g++ -g z3.ii to trigger the bug.
Should the importance of this bug be raised? It is a bit embarrasing that the program #include <openssl/ssl.h> ice's
*** Bug 68351 has been marked as a duplicate of this bug. ***
I may be missing something: I could build latest openssl no problem, but '#include <openssl/ssl.h>\int main(){return 0;}' ICEs on my system's installed openssl (OSX 10.9.5). (In reply to Magnus Fromreide from comment #16) > Should the importance of this bug be raised? > It is a bit embarrasing that the program > > #include <openssl/ssl.h> > > ice's
When you say "latest openssl", do you refer to trunk or 1.0.2d? It seems that the problem is gone from openssl trunk due to a source reorganization but it seems to still be present in 1.0.2d.
(In reply to Magnus Fromreide from comment #19) > When you say "latest openssl", do you refer to trunk or 1.0.2d? It seems > that the problem is gone from openssl trunk due to a source reorganization > but it seems to still be present in 1.0.2d. Just tried building openssl-1.0.2d using 'gcc version 6.0.0 20151108' and had no problems. I also retested '#include <openssl/ssl.h>\int main(){return 0;}' using latest 'gcc version 6.0.0 20151108' and it still ICEs on my system (OSX 10.9.5). [preprocessed files are in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351 ]
Odd. I have just tried with a freshly built gcc and openssl-1.0.2d and the build still fails on line 351 (the definition of struct bn_gencb_st) On the other hand, I am running x86_64-linux, not osx.
For what it's worth, I just checked again openssl-1.0.2d builds fine with 'gcc 6.0.0 20151108' on OSX 10.9.5. Checked it is running the right gcc (both with and without '-g'), configured with 'darwin-i386-cc' and 'darwin64-x86_64-cc'. I wasn't able to break it. (In reply to Magnus Fromreide from comment #21) > Odd. I have just tried with a freshly built gcc and openssl-1.0.2d and the > build still fails on line 351 (the definition of struct bn_gencb_st) > On the other hand, I am running x86_64-linux, not osx.
One more question - you are using the command g++ -g file_that_include_ssl_h.cpp right? Building it as C works for me as well.
Yes, just checked that. 'gcc -g file_that_include_ssl_h.cpp' builds fine, but 'g++ -g file_that_include_ssl_h.cpp' ICEs. (In reply to Magnus Fromreide from comment #23) > One more question - you are using the command > > g++ -g file_that_include_ssl_h.cpp > > right? Building it as C works for me as well.
I've also came across this ICE, with this reduced testcase: template< typename C > class Dl { class __ii { }; typedef __ii It; It ii(typename C::I *e) { return It(e); } }; template<typename E> class X1 { typename E::L foo; }; struct M { struct CO { typedef M I; }; enum Type { }; typedef Dl<CO> L; Type t; struct R { X1<M> f; }; }; With: gcc version 6.0.0 20151119 (experimental) (GCC) t.i: In instantiation of ‘class Dl<M::CO>’: t.i:8:47: required from ‘class X1<M>’ t.i:16:20: required from here t.i:1:30: error: TYPE_CANONICAL is not compatible template< typename C > class Dl ^~ <record_type 0x7f1ccca84d20 M type_5 type_6 VOID align 8 symtab -862572464 alias set -1 canonical type 0x7f1ccca84d20 fields <field_decl 0x7f1ccca8bd10 t type <enumeral_type 0x7f1ccca8c348 Type type <integer_type 0x7f1ccca8c3f0 unsigned int> asm_written unsigned SI size <integer_cst 0x7f1ccc939e58 constant 32> unit size <integer_cst 0x7f1ccc939e70 constant 4> align 32 symtab -862572224 alias set -1 canonical type 0x7f1ccca8c348 precision 32 min <integer_cst 0x7f1ccc95a0f0 0> max <integer_cst 0x7f1ccc95a0d8 4294967295> context <record_type 0x7f1ccca84d20 M> chain <type_decl 0x7f1ccca8bab0 Type>> decl_3 VOID file t.i line 15 col 8 align 1 offset_align 1 context <record_type 0x7f1ccca84d20 M> chain <type_decl 0x7f1ccca8b720 M type <record_type 0x7f1ccca84dc8 M> used nonlocal decl_4 VOID file t.i line 11 col 1 align 1 context <record_type 0x7f1ccca84d20 M> result <record_type 0x7f1ccca84d20 M> chain <type_decl 0x7f1ccca8b850 CO>>> context <translation_unit_decl 0x7f1ccc945168 D.1> full-name "struct M" n_parents=0 use_template=0 interface-unknown pointer_to_this <pointer_type 0x7f1ccca8cc78> chain <type_decl 0x7f1ccca8b688 M>> <record_type 0x7f1ccca8c000 I type_5 VOID align 8 symtab -862572304 alias set -1 canonical type 0x7f1ccca84d20 fields <type_decl 0x7f1ccca8b720 M type <record_type 0x7f1ccca84dc8 M type_5 VOID align 8 symtab 0 alias set -1 canonical type 0x7f1ccca84d20 context <translation_unit_decl 0x7f1ccc945168 D.1> full-name "struct M" n_parents=0 use_template=0 interface-unknown chain <type_decl 0x7f1ccca8b688 M>> used nonlocal decl_4 VOID file t.i line 11 col 1 align 1 context <record_type 0x7f1ccca84d20 M> result <record_type 0x7f1ccca84d20 M type_5 type_6 VOID align 8 symtab -862572464 alias set -1 canonical type 0x7f1ccca84d20 fields <field_decl 0x7f1ccca8bd10 t> context <translation_unit_decl 0x7f1ccc945168 D.1> full-name "struct M" n_parents=0 use_template=0 interface-unknown pointer_to_this <pointer_type 0x7f1ccca8cc78> chain <type_decl 0x7f1ccca8b688 M>> chain <type_decl 0x7f1ccca8b850 CO type <record_type 0x7f1ccca84e70 CO> public decl_2 VOID file t.i line 12 col 10 align 8 context <record_type 0x7f1ccca84d20 M> chain <type_decl 0x7f1ccca8bab0 Type>>> context <translation_unit_decl 0x7f1ccc945168 D.1> full-name "M::CO::I" n_parents=0 use_template=0 interface-unknown pointer_to_this <pointer_type 0x7f1ccca8cbd0> chain <type_decl 0x7f1ccca8b688 M>> t.i:1:30: internal compiler error: verify_type failed 0xf75d1c verify_type(tree_node const*) ../../gcc/gcc/tree.c:13818 0x991de4 gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20739 0x992428 gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20836 0x9932e6 gen_type_die ../../gcc/gcc/dwarf2out.c:20932 0x99efb7 gen_formal_types_die ../../gcc/gcc/dwarf2out.c:18283 0x9978b5 gen_subprogram_die ../../gcc/gcc/dwarf2out.c:19141 0x9996ac gen_decl_die ../../gcc/gcc/dwarf2out.c:21496 0x994563 gen_member_die ../../gcc/gcc/dwarf2out.c:20432 0x994563 gen_struct_or_union_type_die ../../gcc/gcc/dwarf2out.c:20516 0x994563 gen_tagged_type_die ../../gcc/gcc/dwarf2out.c:20717 0x99278d gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20877 0x9932e6 gen_type_die ../../gcc/gcc/dwarf2out.c:20932 0x999c71 gen_decl_die ../../gcc/gcc/dwarf2out.c:21519 0x99a6bc dwarf2out_decl ../../gcc/gcc/dwarf2out.c:21974 0x99a9fb dwarf2out_type_decl ../../gcc/gcc/dwarf2out.c:21684 0xc0175f rest_of_type_compilation(tree_node*, int) ../../gcc/gcc/passes.c:335 0x6b0956 finish_struct_1(tree_node*) ../../gcc/gcc/cp/class.c:6776 0x67ff9b instantiate_class_template_1 ../../gcc/gcc/cp/pt.c:10198 0x67ff9b instantiate_class_template(tree_node*) ../../gcc/gcc/cp/pt.c:10238 0x723f4b complete_type(tree_node*) ../../gcc/gcc/cp/typeck.c:131 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
In the case below (fails to compile ssl.h on OSX 10.9.5), I could simply go to ssl.h lines 337 and 339 and comment out the 'DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER'.. then it compiled no problem. (In reply to Guille from comment #24) > Yes, just checked that. > 'gcc -g file_that_include_ssl_h.cpp' builds fine, but > 'g++ -g file_that_include_ssl_h.cpp' ICEs. > > > (In reply to Magnus Fromreide from comment #23) > > One more question - you are using the command > > > > g++ -g file_that_include_ssl_h.cpp > > > > right? Building it as C works for me as well.
(In reply to Guille from comment #26) > In the case below (fails to compile ssl.h on OSX 10.9.5), > I could simply go to ssl.h lines 337 and 339 and comment out the > 'DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER'.. > then it compiled no problem. I tested that again. Ignore the above comment. One can make it compile as follows. This is the *original* relevant part of ssl.h: 330: struct bn_gencb_st { unsigned int ver; /* To handle binary (in)compatibility */ void *arg; /* callback-specific data */ union 335: { /* if(ver==1) - handles old style callbacks */ void (*cb_1)(int, int, void *) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER; /* if(ver==2) - new callback style */ int (*cb_2)(int, int, BN_GENCB *) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER; 340: } cb; }; take the union outside the struct and give it a name: union bn_gencb_st__cb_t { void (*cb_1)(int, int, void *) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER; int (*cb_2)(int, int, BN_GENCB *) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER; }; struct bn_gencb_st { unsigned int ver; void *arg; bn_gencb_st__cb_t cb; }; then it compiles fine. > > > (In reply to Guille from comment #24) > > Yes, just checked that. > > 'gcc -g file_that_include_ssl_h.cpp' builds fine, but > > 'g++ -g file_that_include_ssl_h.cpp' ICEs. > > > > > > (In reply to Magnus Fromreide from comment #23) > > > One more question - you are using the command > > > > > > g++ -g file_that_include_ssl_h.cpp > > > > > > right? Building it as C works for me as well.
Unassigning myself; I suggested a fix at https://gcc.gnu.org/ml/gcc-patches/2015-11/threads.html#03102 but richi and honza have been discussing other ways of addressing the bug. honza checked in one of the patches we were discussing today, along with the ipa/61886 fix; I'm guessing that was unintended but should mean the bug is fixed.
Yes, I've re-tested all of the test case snipits herein and they all pass with current mainline.