Bug 11274 - [3.3/3.4 regression] Segfault in hash_type
Summary: [3.3/3.4 regression] Segfault in hash_type
Status: RESOLVED DUPLICATE of bug 11249
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 3.3.1
Assignee: Not yet assigned to anyone
Depends on: 11249
  Show dependency treegraph
Reported: 2003-06-20 20:32 UTC by Wolfgang Bangerth
Modified: 2004-01-17 04:22 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2003-06-22 17:05:49

preprocessed sources (123.92 KB, text/plain)
2003-06-20 20:34 UTC, Wolfgang Bangerth
Small but most likely not minimal testcase (383 bytes, text/plain)
2003-06-21 15:36 UTC, Christian Ehrhardt
reduced testcase (207 bytes, text/plain)
2003-06-22 17:03 UTC, Christian Ehrhardt

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Bangerth 2003-06-20 20:32:11 UTC
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.

Comment 1 Wolfgang Bangerth 2003-06-20 20:34:02 UTC
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.
Comment 2 Wolfgang Bangerth 2003-06-21 00:55:14 UTC
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
Comment 3 Andrew Pinski 2003-06-21 04:39:37 UTC
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.
Comment 4 Christian Ehrhardt 2003-06-21 12:42:55 UTC
Will come up with reduced testcase.
Comment 5 Giovanni Bajo 2003-06-21 13:18:45 UTC
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.
Comment 6 Franz Sirl 2003-06-21 13:51:50 UTC
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 
Comment 7 Christian Ehrhardt 2003-06-21 15:36:17 UTC
Created attachment 4261 [details]
Small but most likely not minimal testcase
Comment 8 Christian Ehrhardt 2003-06-22 17:03:13 UTC
Created attachment 4265 [details]
reduced testcase
Comment 9 Wolfgang Bangerth 2003-06-22 17:58:04 UTC
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.

Comment 10 Giovanni Bajo 2003-06-22 20:53:34 UTC
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 ***