From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16438 invoked by alias); 5 Jun 2015 14:02:34 -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 15760 invoked by uid 89); 5 Jun 2015 14:02:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_20,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:02: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 (Postfix) with ESMTPS id B00158F294; Fri, 5 Jun 2015 14:02:26 +0000 (UTC) Received: from [10.10.116.25] ([10.10.116.25]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t55E2PFo016271; Fri, 5 Jun 2015 10:02:25 -0400 Message-ID: <5571ABED.8090808@redhat.com> Date: Fri, 05 Jun 2015 14:02:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Aldy Hernandez , 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> In-Reply-To: <5570DFBA.9080407@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00464.txt.bz2 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? 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 (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; } Jason