My log files tell me that this has been broken on mainline sometime in the last two days. It's kind of evasive, if I change something, the ICE moves to another place or vanishes altogether. Unfortunately, I don't have the time right now to reduce the testcase further. Better post it right now, though, maybe someone else has the time or wants to find the offending patch. W.
Created attachment 4260 [details] preprocessed sources I should also say what happens, I guess :-) deal.II/deal.II> c++ -c multigrid.all_dimensions.ii <internal>: In instantiation of `SmartPointer<const MGMatrixBase<Vector<double> > >': <internal>:43088: instantiated from `Multigrid<Vector<double> >' <internal>:43130: instantiated from here <internal>:28442: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Here's a backtrace: #0 0x0815522b in hash_type (val=0x0) at ../../gcc/gcc/cp/mangle.c:2600 #1 0x08486857 in htab_expand (htab=0x405d7dc0) at ../../gcc/libiberty/hashtab.c:409 #2 0x08486b42 in htab_find_slot_with_hash (htab=0x405d7dc0, element=0x42882948, hash=139527465, insert=INSERT) at ../../gcc/libiberty/hashtab.c:510 #3 0x08155302 in mangle_conv_op_name_for_type (type=0x42882948) at ../../gcc/gcc/cp/mangle.c:2625 #4 0x080a1532 in tsubst_decl (t=0x4171d4a4, args=0x42883280, type=0x4288521c, complain=tf_error) at ../../gcc/gcc/cp/pt.c:6032 #5 0x0809da80 in instantiate_class_template (type=0x1) at ../../gcc/gcc/cp/pt.c:5344 #6 0x0810d7d2 in complete_type (type=0x405d7dc0) at ../../gcc/gcc/cp/typeck.c:151 #7 0x0809df3e in instantiate_class_template (type=0x1) at ../../gcc/gcc/cp/pt.c:5389 #8 0x0810d7d2 in complete_type (type=0x405d7dc0) at ../../gcc/gcc/cp/typeck.c:151 #9 0x080b5c18 in do_type_instantiation (t=0x1, storage=0x0, complain=tf_error) at ../../gcc/gcc/cp/pt.c:10367 #10 0x080ffd99 in cp_parser_explicit_instantiation (parser=0x1) at ../../gcc/gcc/cp/parser.c:8325 #11 0x080fe022 in cp_parser_declaration (parser=0x405d7dc0) at ../../gcc/gcc/cp/parser.c:6413 #12 0x080fde78 in cp_parser_declaration_seq_opt (parser=0x405d7dc0) at ../../gcc/gcc/cp/parser.c:6337 #13 0x080f9802 in cp_parser_translation_unit (parser=0x40495400) at ../../gcc/gcc/cp/parser.c:2256 #14 0x08107592 in yyparse () at ../../gcc/gcc/cp/parser.c:14671 #15 0x08180446 in c_common_parse_file (set_yydebug=0) at ../../gcc/gcc/c-opts.c:1199 #16 0x083bc4da in compile_file () at ../../gcc/gcc/toplev.c:2178 #17 0x083c2177 in do_compile () at ../../gcc/gcc/toplev.c:5507 #18 0x083c21e8 in toplev_main (argc=0, argv=0xbfffe0a4) at ../../gcc/gcc/toplev.c:5536 #19 0x081843eb in main (argc=0, argv=0x0) at ../../gcc/gcc/main.c:37 #20 0x400465cd in __libc_start_main () from /lib/libc.so.6
Still a c++ problem because of going though mangle.c and it looks like related to bug 11249 which also goes though mangle_conv_op_name_for_type.
Will come up with reduced testcase.
Christian, you may want to wait for Mark to look into PR11249. The bug seems exactly the same, and the code crashes on a very new piece of code added by Mark lately. If Mark fixes PR11249, this PR could get fixed automatically.
Seen on powerpc-linux with gcc-3_3-branch and gcc-3_3-rhl-branch. I have two testcases from kvirc and kdelibs, if more data is needed. BTW, the preprocessed kvirc testcase spits out this tree check ICE if compiled with a i686-linux 3_3 compiler: [fsirl@linuxpc1:/home/gnu/obj/gcc33/gcc]$ stage2/xgcc -Bstage2/ ~/libkvisnd.ii In file included from /usr/include/kde/arts/soundserver.h:10, from libkvisnd.cpp:68: /usr/include/kde/arts/kmedia2.h:692: internal compiler error: tree check: expected tree_list, have asm_stmt in compare_type, at cp/mangle.c:2637
Created attachment 4261 [details] Small but most likely not minimal testcase
Created attachment 4265 [details] reduced testcase
Janis was so kind as to run her regression scripts on this bug. This is what she sent me: On Fri, Jun 20, 2003 at 07:19:42PM -0500, Wolfgang Bangerth wrote: > > > I think this is a Heisenbug. It fails with a compiler from 2002-02-25. > > You have a point. I can see all kind of weird errors, ICEs and other stuff > running it through my compiler collection. > > > If you still have your collection of cc1plus binaries, try them with it; > > otherwise I can use my reg_periodic script to see if it's really failing > > randomly. > > Nevertheless, this is code that used to compile every night, so I think it > would be interesting which patch _exposed_ (not introduced) the present > behavior. Can your scripts do something like this? For compilers that didn't > ICE, you'll get an error (from my incomplete attempts to reduce the > testcase), but it shouldn't ICE. The current ICE in 11274 was introduced/exposed with this patch: --- gcc/gcc/cp/ChangeLog --- > 2003-06-17 Mark Mitchell <mark@codesourcery.com> > > PR c++/11105 > * cp-tree.h (DECL_CONV_FN_TYPE): New method. > * mangle.c (struct globals): Remove internal_mangling_p. > (write_unqualified_name): Use DECL_CONV_FN_TYPE. > (write_template_parm): Don't write out the level number. > (conv_type_names): New variable. > (hash_type): New function. > (compare_type): Likewise. > (mangle_conv_op_name_for_type): Don't try to mangle conversion > operator names. > * search.c (lookup_conversion_operator): New function. > (lookup_fnfields_1): Use it. I used reg_periodic (available in contrib/reghunt) to check compilers built every four hours from June 16 to June 20; the behavior is consistent during that time. My laptop's browser flakes out when I use it from home, so I can't update Bugzilla until tomorrow. Feel free to add this information yourself if you'd like it to be there today. I have a few other hunts going this weekend, but haven't been able to monitor them very well so I'm not making much progress. Janis
Duplicate of 11249. Very similar testcase, the same patch introduced the regression, ICE in the same position. *** This bug has been marked as a duplicate of 11249 ***