Hi C++ folks,
While debugging a patch, I stumbled across some kind of synthetic cdtor that
crashes debug_tree():
> Breakpoint 5, i386_pe_encode_section_info (decl=0x7f9b3e00, rtl=0x7f902220,
> first=1) at /gnu/gcc/gcc/gcc/config/i386/winnt.c:252
> 252 default_encode_section_info (decl, rtl, first);
> (gdb) call debug_tree (decl)
> <function_decl 0x7f9b3e00 __comp_dtor
> type <method_type 0x7f89cab8
> type <void_type 0x7fdc08f0 void type_6 VOID
> align 8 symtab 0 alias set -1 canonical type 0x7fdc08f0
> pointer_to_this <pointer_type 0x7fdc0958>>
> QI
> size <integer_cst 0x7fef0400 constant 8>
> unit size <integer_cst 0x7fef0420 constant 1>
> align 8 symtab 0 alias set -1 canonical type 0x7f89ca50 method
> basetype
> <record_type 0x7fa29da0 _Alloc_hider>
> arg-types <tree_list 0x7f8c3840 value <pointer_type 0x7fa29f40>
> chain <tree_list 0x7fef0bc0 value <void_type 0x7fdc08f0 void>>>
> pointer_to_this <pointer_type 0x7f89ccc0>>
> addressable asm_written used nothrow public static in_system_header
> autoinli
> ne decl_3 decl_5 QI file
> /gnu/gcc/install-libstdc-latest/opt/gcc-tools/bin/../li
> b/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/basic_string.h line 258 col 7
> align
> 16 initial <block 0x7f9ab9f0> abstract_origin <function_decl 0x7f9b3d80
> _Alloc_h
> ider>
> arguments <parm_decl 0x7f8ac990 this
> type <pointer_type 0x7fa2a010 type <record_type 0x7fa29da0
> _Alloc_hider>
>
> readonly unsigned SI
> size <integer_cst 0x7fef05c0 constant 32>
> unit size <integer_cst 0x7fef0360 constant 4>
> align 32 symtab 0 alias set -1 canonical type 0x7fa2a010>
> readonly used unsigned SI file
> /gnu/gcc/install-libstdc-latest/opt/gcc-t
> ools/bin/../lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/basic_string.h line
> 50
> 3 col 54 size <integer_cst 0x7fef05c0 32> unit size <integer_cst 0x7fef0360 4>
> align 32 context <function_decl 0x7f9b3e00 __comp_dtor >
> abstract_origin
> <parm_decl 0x7f8ac8f0 this>
> (mem/f/c/i:SI (reg/f:SI 16 argp) [0 this+0 S4 A32]) arg-type
> <pointer_ty
> pe 0x7fa2a010>
> incoming-rtl (mem/f/c/i:SI (reg/f:SI 16 argp) [0 this+0 S4 A32])>
> result <result_decl 0x7f8acb70 D.11470 type <void_type 0x7fdc08f0 void>
> ignored VOID file
> /gnu/gcc/install-libstdc-latest/opt/gcc-tools/bin/../l
> ib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/basic_string.h line 258 col 7
> align 8 context <function_decl 0x7f9b3e00 __comp_dtor >>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x004cb6d2 in dump_function_name (t=0x7f9b3e00, flags=116)
> at /gnu/gcc/gcc/gcc/cp/error.c:1433
> 1433 if (LAMBDA_TYPE_P (DECL_CONTEXT (t)))
> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on"
> Evaluation of the expression containing the function (debug_tree) will be
> abando
> ned.
> (gdb)
The crash happens when calling dump_function_name in cp/error.c:
/* Handle the function name for a FUNCTION_DECL node, grokking operators
and destructors properly. */
static void
dump_function_name (tree t, int flags)
{
tree name = DECL_NAME (t);
/* We can get here with a decl that was synthesized by language-
independent machinery (e.g. coverage.c) in which case it won't
have a lang_specific structure attached and DECL_CONSTRUCTOR_P
will crash. In this case it is safe just to print out the
literal name. */
if (!DECL_LANG_SPECIFIC (t))
{
pp_cxx_tree_identifier (cxx_pp, name);
return;
}
if (TREE_CODE (t) == TEMPLATE_DECL)
t = DECL_TEMPLATE_RESULT (t);
/* Don't let the user see __comp_ctor et al. */
if (DECL_CONSTRUCTOR_P (t)
|| DECL_DESTRUCTOR_P (t))
{
if (LAMBDA_TYPE_P (DECL_CONTEXT (t)))
name = get_identifier ("<lambda>");
else
name = constructor_name (DECL_CONTEXT (t));
}
... here. The node in question does have a lang-specific entry, but the
context is NULL, crashing the call to LAMBDA_TYPE_P.
I reproduced it on an unpatched build of r.154010 just to make sure my patch
wasn't the cause.
Is it valid for the context to be NULL here? The testcase that provoked it
is simple:
> #include <string>
> extern void bar (std::string x);
>
> int main (int argc, const char **argv)
> {
>
> std::string foo = "abc";
> foo += argv[1];
> bar (foo);
> }
... so I guess I can see why we're not in any class or namespace context here;
is the problem perhaps that the cdtor in question here is a template
instantiation, and we need to look at the template decl to find the context
rather than the instantiation decl? I see an entry in cp/ChangeLog-2000 that
says "* error.c (dump_function_name): Don't let the user see __comp_ctor" but
I'm not sure what the user should be seeing instead.
cheers,
DaveK
