From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7668 invoked by alias); 5 Jun 2015 14:58:17 -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 7613 invoked by uid 89); 5 Jun 2015 14:58:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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; Fri, 05 Jun 2015 14:58:16 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id F413C36B4E2; Fri, 5 Jun 2015 14:58:14 +0000 (UTC) Received: from reynosa.quesejoda.com (vpn-57-97.rdu2.redhat.com [10.10.57.97]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t55EwD1h031500; Fri, 5 Jun 2015 10:58:13 -0400 Message-ID: <5571B904.3090609@redhat.com> Date: Fri, 05 Jun 2015 15:24:00 -0000 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jason Merrill , Richard Biener CC: gcc-patches Subject: Re: [debug-early] fix problem with template parameter packs References: <55482AF6.1090207@redhat.com> <5549314D.6080804@redhat.com> <5549373F.6020503@redhat.com> <554A4146.4010501@redhat.com> <5564A158.8010604@redhat.com> <55661C58.6040305@redhat.com> <556EFB62.3040209@redhat.com> <556F1256.1030400@redhat.com> <557097BB.4080709@redhat.com> <55709B60.7050004@redhat.com> <5570DFBA.9080407@redhat.com> <5571ABED.8090808@redhat.com> In-Reply-To: <5571ABED.8090808@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00467.txt.bz2 On 06/05/2015 10:02 AM, Jason Merrill wrote: > On 06/04/2015 07:31 PM, Aldy Hernandez wrote: >> So... if I revert the !declaration change and move the big block below >> said change, would you be OK with it, or did you still want some changes >> to it? > > I'm still hoping to simplify it. Actually, I think we can just remove the > >> if (old_die && declaration && !local_scope_p (context_die)) > > check; since inverting its logic didn't seem to break anything before, > it can just go. > > And I'd like to rework the logic in the big block so we don't have three > ways of getting to the same thing. Does this work? g++.dg/debug/dwarf2/static-data-member1.C fails because it doesn't get a DW_AT_specification. How about: if (old_die) { if (declaration) { /* A declaration that has been previously dumped, needs no further annotations, since it doesn't need location on the second pass. */ return; } else if (decl_will_get_specification_p (old_die, decl, declaration) && !get_AT (old_die, DW_AT_specification)) { /* Fall-thru so we can make a new variable die along with a DW_AT_specification. */ } else if (origin && old_die->die_parent != context_die) { /* If we will be creating an inlined instance, we need a new DIE that will get annotated with DW_AT_abstract_origin. Clear things so we can get a new DIE. */ gcc_assert (!DECL_ABSTRACT_P (decl)); old_die = NULL; } else { /* If a DIE was dumped early, it still needs location info. Skip to where we fill the location bits. */ var_die = old_die; goto gen_variable_die_location; } }