From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96139 invoked by alias); 18 Mar 2015 15:51:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 96084 invoked by uid 89); 18 Mar 2015 15:51:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 18 Mar 2015 15:51:09 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2IFp81x029572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 18 Mar 2015 11:51:08 -0400 Received: from reynosa.quesejoda.com (vpn-54-165.rdu2.redhat.com [10.10.54.165]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2IFp7GK025766; Wed, 18 Mar 2015 11:51:07 -0400 Message-ID: <55099EEB.70402@redhat.com> Date: Wed, 18 Mar 2015 15:51:00 -0000 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jason Merrill CC: gcc-patches Subject: Re: [debug-early] equate new DIE with DW_AT_specificationto a previous declaration References: <5508874D.70008@redhat.com> <5508DF27.9060607@redhat.com> In-Reply-To: <5508DF27.9060607@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00952.txt.bz2 On 03/17/2015 07:12 PM, Jason Merrill wrote: > On 03/17/2015 03:58 PM, Aldy Hernandez wrote: >> The problem is that, for -fno-implicit-templates, the decl is now >> DECL_EXTERNAL, which means we never equate this new "DIE with >> DW_AT_specification" to the DECL. That is, we never fall through here: >> >> else if (!DECL_EXTERNAL (decl)) >> { >> HOST_WIDE_INT cfa_fb_offset; >> >> struct function *fun = DECL_STRUCT_FUNCTION (decl); >> >> if (!old_die || !get_AT (old_die, DW_AT_inline)) >> equate_decl_number_to_die (decl, subr_die); >> >> However, when we call gen_subprogram_die() the third time through the >> outlining_inline_function hook (late debug), we again try to add a >> DW_AT_specification to the DIE cached from the first time around, but >> this time we ICE because we're not supposed to have multiple >> DW_AT_specification's pointing to the same DIE (the old original DIE). > > Why are we outlining a DECL_EXTERNAL function? SRA is analyzing Object::Method() and noticing that `this' is never used, so it's trying to rewrite the call to avoid passing `this' (by creating a clone). SRA has no restrictions on whether a function is DECL_EXTERNAL. For that matter, the SRA pass is called on all functions that have a gimple body, irregardless of DECL_EXTERNAL, courtesy of the pass manager: if (node->has_gimple_body_p ()) callback (DECL_STRUCT_FUNCTION (node->decl), data); ...and since Object::Method() has a gimple body even though it is marked DECL_EXTERNAL...we get the call into dwarf2out_abstract_decl. > > Incidentally, > >> /* If we have no location information, this must be a >> partially generated DIE from early dwarf generation. >> Fall through and generate it. */ > > Why aren't we checking dumped_early here? Good point. I'll add an assert. Aldy