This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
c++/9778: [3.4 regression] ICE with sizeof(expr) in non-type template arg
- From: bangerth at ticam dot utexas dot edu
- To: gcc-gnats at gcc dot gnu dot org
- Date: 20 Feb 2003 17:14:29 -0000
- Subject: c++/9778: [3.4 regression] ICE with sizeof(expr) in non-type template arg
- Reply-to: bangerth at ticam dot utexas dot edu
>Number: 9778
>Category: c++
>Synopsis: [3.4 regression] ICE with sizeof(expr) in non-type template arg
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Feb 20 17:16:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: Wolfgang Bangerth
>Release: unknown-1.0
>Organization:
>Environment:
present mainline
>Description:
This started SegFaulting somewhere between 2003-01-12 and
2003-01-30:
-------------------------------
namespace NS {
template <int N> void foo ();
}
template <int N> struct X {
int m;
int g () {
NS::foo<sizeof(m)>();
}
};
template class X<2>;
--------------------------
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c y.cc
y.cc: In member function `int X<N>::g() [with int N = 2]':
y.cc:12: instantiated from here
y.cc:8: internal compiler error: Segmentation fault
Here's a backtrace:
#0 0x4009db33 in strlen () from /lib/libc.so.6
#1 0x08146004 in write_expression (expr=0x4015dfa0)
at ../../gcc-3.4-CVS/gcc/cp/mangle.c:1985
#2 0x0814659f in write_expression (expr=0x4015dfa0)
at ../../gcc-3.4-CVS/gcc/cp/mangle.c:2017
#3 0x0814659f in write_expression (expr=0x401965f0)
at ../../gcc-3.4-CVS/gcc/cp/mangle.c:2017
#4 0x08146dae in write_template_arg (node=0x401965f0)
at ../../gcc-3.4-CVS/gcc/cp/mangle.c:2133
#5 0x08145dae in write_template_args (args=0x40196690)
at ../../gcc-3.4-CVS/gcc/cp/mangle.c:1812
#6 0x08143792 in write_nested_name (decl=0x4019857c)
at ../../gcc-3.4-CVS/gcc/cp/mangle.c:841
#7 0x08143361 in write_name (decl=0x4019857c, ignore_local_scope=0)
at ../../gcc-3.4-CVS/gcc/cp/mangle.c:763
The place where this happens is incidentally the same as
that noted in PR 9749, though that is a regression
introduced long ago. Maybe somewhen in the time frame
noted above some code path just started to use the same
path as that in 9749. If so, then one should be able
to squash both bugs with one patch.
The underlying problem is the following: we segfault
in strlen called from write_expression in this hunk:
/* If it wasn't any of those, recursively expand the expression. */
write_string (operator_name_info[(int) code].mangled_name);
In the testcase
(gdb) fr 1
#1 0x08146004 in write_expression (expr=0x4015dfa0)
at ../../gcc-3.4-CVS/gcc/cp/mangle.c:1985
(gdb) p code
$5 = IDENTIFIER_NODE
(gdb) p (int)code
$6 = 1
(gdb) p operator_name_info[1]
$7 = {identifier = 0x0, name = 0x0, mangled_name = 0x0, arity = 0}
W.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: