From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24577 invoked by alias); 28 Jan 2015 18:34:00 -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 24544 invoked by uid 89); 28 Jan 2015 18:33:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 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, 28 Jan 2015 18:33:58 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0SIXu0E018841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 28 Jan 2015 13:33:56 -0500 Received: from reynosa.quesejoda.com (vpn-61-230.rdu2.redhat.com [10.10.61.230]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0SIXsJH013587; Wed, 28 Jan 2015 13:33:55 -0500 Message-ID: <54C92B92.30601@redhat.com> Date: Wed, 28 Jan 2015 19:44:00 -0000 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Richard Biener , Jason Merrill CC: gcc-patches Subject: Re: [debug-early] C++ clones and limbo DIEs References: <54B87E5B.1090502@redhat.com> <54B88149.1040906@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-01/txt/msg02523.txt.bz2 On 01/16/2015 02:55 AM, Richard Biener wrote: > On Fri, Jan 16, 2015 at 4:11 AM, Jason Merrill wrote: >> On 01/15/2015 09:58 PM, Aldy Hernandez wrote: > I hoped we wouldn't need the limbo list at all ... that is, parent DIEs > are always present when we create children. I think that should > work in principle if the frontends would create DIEs while parsing. By the way, don't think I ignored this suggestion. I played around with this approach for the C++ front-end, and gave up after having to keep track of a few too many things to get the parenthood right. It's totally doable; it was just easier to flush out the limbo DIE list as with my current patch. Ok, call me lazy :). > Note that dwarf2out forces parent DIE creation in some cases > but not in some others - it would be interesting to sort out which > parent DIEs it thinks it cannot create when we create the DIE > for a sibling. Maybe it's just poor ordering of early_global_decl > calls? In my current patch, I added an ICE to make sure we're not creating limbo destined DIEs past early dwarf dumping. The only exception to this (temporarily) is that the ltrans stage is adding things late, but that's only because we're not streaming dwarf as the ultimate plan is. I've documented all this. Aldy