This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/9452: [2003-05-03] ICE (segfault) using a dependent expressionas argument for the template-id in the return type
- From: Wolfgang Bangerth <bangerth at ices dot utexas dot edu>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 16 May 2003 20:06:01 -0000
- Subject: Re: c++/9452: [2003-05-03] ICE (segfault) using a dependent expressionas argument for the template-id in the return type
- Reply-to: Wolfgang Bangerth <bangerth at ices dot utexas dot edu>
The following reply was made to PR c++/9452; it has been noted by GNATS.
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: Giovanni Bajo <giovannibajo@libero.it>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>,
Gabriel Dos Reis <gdr@integrable-solutions.net>
Subject: Re: c++/9452: [2003-05-03] ICE (segfault) using a dependent expression
as argument for the template-id in the return type
Date: Fri, 16 May 2003 15:02:12 -0500 (CDT)
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9452
>
> I think the segfault happens while trying to format the error message.
No, that's not the case. The error happens here (this is present mainline):
#0 convert_from_reference (val=0x40159528)
at ../../gcc-3.4-CVS/gcc/cp/cvt.c:557
#1 0x08052c35 in prep_operand (operand=0x40159528)
at ../../gcc-3.4-CVS/gcc/cp/call.c:3561
#2 0x08052f79 in build_new_op (code=MINUS_EXPR, flags=3, arg1=0x40159528,
arg2=0x401a0f28, arg3=0x0) at ../../gcc-3.4-CVS/gcc/cp/call.c:3662
#3 0x081143f6 in build_x_binary_op (code=MINUS_EXPR, arg1=0x40159528,
arg2=0x0) at ../../gcc-3.4-CVS/gcc/cp/typeck.c:2947
#4 0x0809e635 in tsubst_template_arg_vector (t=0x401a0f50, args=0x40159510,
complain=tf_none) at ../../gcc-3.4-CVS/gcc/cp/pt.c:5676
#5 0x0809ed80 in tsubst_aggr_type (t=0x401aabd0, args=0x40159510,
complain=tf_none, in_decl=0x0, entering_scope=0)
at ../../gcc-3.4-CVS/gcc/cp/pt.c:5794
#6 0x080a2d7c in tsubst (t=0x401aac3c, args=0x40159510, complain=tf_none,
in_decl=0x0) at ../../gcc-3.4-CVS/gcc/cp/pt.c:6578
#7 0x080a1f34 in tsubst_function_type (t=0x401aac3c, args=0x40159510,
complain=tf_none, in_decl=0x401aabd0) at ../../gcc-3.4-CVS/gcc/cp/pt.c:6445
#8 0x080a30e8 in tsubst (t=0x401ad000, args=0x40159510, complain=tf_none,
in_decl=0x0) at ../../gcc-3.4-CVS/gcc/cp/pt.c:6960
#9 0x080aedbd in fn_type_unification (fn=0x401ad0d8, explicit_targs=0x0,
targs=0x401ad000, args=0x401ac7bc, return_type=0x0, strict=DEDUCE_CALL,
len=-1) at ../../gcc-3.4-CVS/gcc/cp/pt.c:8649
The place in convert_reference is this:
tree
convert_from_reference (tree val)
{
tree type = TREE_TYPE (val);
if (TREE_CODE (type) == OFFSET_TYPE) -------- here
type = TREE_TYPE (type);
if (TREE_CODE (type) == REFERENCE_TYPE)
return build_indirect_ref (val, NULL);
return val;
}
and the reason is that type==0x0. Now, as to why that is happening...
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/