From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13854 invoked by alias); 18 Nov 2009 12:44:17 -0000 Received: (qmail 13846 invoked by uid 22791); 18 Nov 2009 12:44:16 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-bw0-f211.google.com (HELO mail-bw0-f211.google.com) (209.85.218.211) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Nov 2009 12:43:24 +0000 Received: by bwz3 with SMTP id 3so1210389bwz.16 for ; Wed, 18 Nov 2009 04:43:21 -0800 (PST) Received: by 10.204.34.18 with SMTP id j18mr6384607bkd.38.1258548201185; Wed, 18 Nov 2009 04:43:21 -0800 (PST) Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id 16sm7282fxm.8.2009.11.18.04.43.19 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 04:43:20 -0800 (PST) Message-ID: <4B03EF94.1050305@gmail.com> Date: Wed, 18 Nov 2009 12:44:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "gcc@gcc.gnu.org" Subject: C++ comp_cdtor FUNCTION_DECL tree nodes with DECL_LANG_SPECIFIC but no DECL_CONTEXT: valid or not? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00456.txt.bz2 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) > type type align 8 symtab 0 alias set -1 canonical type 0x7fdc08f0 > pointer_to_this > > QI > size > unit size > align 8 symtab 0 alias set -1 canonical type 0x7f89ca50 method basetype > > arg-types > chain >> > pointer_to_this > > 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 abstract_origin ider> > arguments type > > readonly unsigned SI > size > unit size > 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 unit size > align 32 context abstract_origin > > (mem/f/c/i:SI (reg/f:SI 16 argp) [0 this+0 S4 A32]) arg-type pe 0x7fa2a010> > incoming-rtl (mem/f/c/i:SI (reg/f:SI 16 argp) [0 this+0 S4 A32])> > result > 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 > > > 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 (""); 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 > 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