This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/8332: strlen/template interaction causes ICE
- From: bangerth at dealii dot org
- To: gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, martin dot dorey at bluearc dot com, nobody at gcc dot gnu dot org
- Date: 28 Oct 2002 21:27:46 -0000
- Subject: Re: c++/8332: strlen/template interaction causes ICE
- Reply-to: bangerth at dealii dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, martin dot dorey at bluearc dot com, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Synopsis: strlen/template interaction causes ICE
State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Mon Oct 28 13:27:44 2002
State-Changed-Why:
I _can_ reproduce this. The bug goes away, if strlen is
renamed, or if its return type is changed to "int", so I
assume this has something to do with built-ins. However,
since the code also SegFaults if we include <string.h>, I
have no reason to believe that this code is wrong. I'd think
this is a serious regression from previous releases!
For more information: the SegFault occurs here:
#0 write_builtin_type (type=0x0) at ../../gcc-3.2/gcc/cp/mangle.c:1569
#1 0x080bbfc5 in write_type (type=0x401888c0)
at ../../gcc-3.2/gcc/cp/mangle.c:1399
#2 0x080bc8df in write_template_args (args=0x4019ec80)
at ../../gcc-3.2/gcc/cp/mangle.c:1789
#3 0x080bb13f in write_name (decl=0x401aac40, ignore_local_scope=0)
at ../../gcc-3.2/gcc/cp/mangle.c:719
#4 0x080bafd3 in write_encoding (decl=0x401aac40)
at ../../gcc-3.2/gcc/cp/mangle.c:654
#5 0x080bd586 in mangle_decl_string (decl=0x401aac40)
at ../../gcc-3.2/gcc/cp/mangle.c:630
The code in question is
/* TYPE may still be wchar_t, since that isn't in
integer_type_nodes. */
if (type == wchar_type_node)
write_char ('w');
else if (TYPE_FOR_JAVA (type)) <<<<< here
write_java_integer_type_codes (type);
else
and the reason is that type==0. On one frame higher, this
code is called from
write_builtin_type (TYPE_MAIN_VARIANT (type));
Here, type is still!=0, but given the nesting of macros,
this is the point where I leave the rest to someone else.
Regards
Wolfgang
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8332