From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27878 invoked by alias); 30 Sep 2014 15:06:27 -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 27867 invoked by uid 89); 30 Sep 2014 15:06:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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; Tue, 30 Sep 2014 15:06:25 +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 s8UF6NdV011524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Sep 2014 11:06:23 -0400 Received: from reynosa.quesejoda.com (vpn-61-24.rdu2.redhat.com [10.10.61.24]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8UF6L0D030179; Tue, 30 Sep 2014 11:06:21 -0400 Message-ID: <542AC6EC.8010408@redhat.com> Date: Tue, 30 Sep 2014 15:06:00 -0000 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Richard Biener CC: gcc-patches Subject: Re: [debug-early] rearrange some checks in gen_subprogram_die References: <5429AAD6.7070708@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg02655.txt.bz2 On 09/30/14 03:23, Richard Biener wrote: > On Mon, Sep 29, 2014 at 8:54 PM, Aldy Hernandez wrote: >> I'm rearranging some code in Michael's original patch to minimize the >> difference with mainline. >> >> It seems that the check for DECL_STRUCT_FUNCTION (decl)->gimple_df, was >> merely a check to see if we had already set the FDE bits for the decl in >> question. > > Sounds more like a check whether the frontend is finished? Is that the canonical way for checking the FE is finished? Seems kinda odd. I'd prefer to check for ->fde, since this is the actual reason the rest of dwarf generation will not work in this case. Either way, I'm not terribly attached to this particular part of the patch. If you'd rather me use ->gimple_df, I can use it. It just doesn't seem very readable. Aldy