From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12010 invoked by alias); 28 Jan 2015 18:51:32 -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 11911 invoked by uid 89); 28 Jan 2015 18:51:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.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, 28 Jan 2015 18:51:27 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0SIpOtt010719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 28 Jan 2015 13:51:25 -0500 Received: from [10.10.116.40] ([10.10.116.40]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0SIpNSW000437; Wed, 28 Jan 2015 13:51:23 -0500 Message-ID: <54C92FA8.9040005@redhat.com> Date: Wed, 28 Jan 2015 19:47:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Aldy Hernandez CC: Richard Biener , gcc-patches Subject: Re: [debug-early] C++ clones and limbo DIEs References: <54B87E5B.1090502@redhat.com> <54B88149.1040906@redhat.com> <54B94F4D.4040009@redhat.com> <54B97854.7040007@redhat.com> <54C296B5.4050506@redhat.com> <54C7FA41.8010903@redhat.com> <54C92A59.4070401@redhat.com> <54C92A80.80306@redhat.com> In-Reply-To: <54C92A80.80306@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-01/txt/msg02524.txt.bz2 On 01/28/2015 01:29 PM, Aldy Hernandez wrote: > + /* It is rather unfortunate that Cilk creates trees this late > + (during gimplification). However, until this gets fixed, > + specially handle emitting DWARF for this new function and > + immediately clean up the limbo_die_list where the new function's > + DIE will inevitably end up. */ Why does it go on limbo_die_list at all? > I noticed dwarf2out's gen_member_die() disallows generation of clones earlier, by design: > > /* Don't include clones in the member list. */ > if (DECL_ABSTRACT_ORIGIN (member)) > continue; > > I played around trying to disable this "feature", but my approach ran into various walls, and I decided instead to attack it from the front-end side. The attached patch generates early DIEs for the C++ clones in the C++ parser. I'd be (un)happy to revisit the dwarf2out approach if it's deemed more appropriate. I'd still like to understand why disabling this doesn't work; I don't like the special handling of clones in the front end. Jason