From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108289 invoked by alias); 28 Oct 2015 14:16:18 -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 108276 invoked by uid 89); 28 Oct 2015 14:16:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_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; Wed, 28 Oct 2015 14:16:17 +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 (Postfix) with ESMTPS id 04EEB8E24C; Wed, 28 Oct 2015 14:16:15 +0000 (UTC) Received: from localhost.localdomain (vpn1-6-138.ams2.redhat.com [10.36.6.138]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9SEGEM1003760; Wed, 28 Oct 2015 10:16:15 -0400 Subject: Re: [ping] Re: Fix PR debug/66728 To: Ulrich Weigand , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com References: <20151028115839.1E7C85C3D@oc7340732750.ibm.com> <87ziz3ta4t.fsf@e105548-lin.cambridge.arm.com> From: Bernd Schmidt Message-ID: <5630D8AE.1090608@redhat.com> Date: Wed, 28 Oct 2015 14:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87ziz3ta4t.fsf@e105548-lin.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg03038.txt.bz2 On 10/28/2015 02:06 PM, Richard Sandiford wrote: > Ulrich Weigand writes: >> seems this still hasn't gone upstream ... Any news? > > Ah, sorry, I should have been pinging it. I think it's still waiting > for review. Hmm, unfortunately I have a hard time making sense of this patch. Some extra explanation would be appreciated. >>> static bool >>> -add_const_value_attribute (dw_die_ref die, rtx rtl) >>> +add_const_value_attribute (dw_die_ref die, machine_mode mode, rtx rtl) Need to document the extra parameter, especially in light of the TYPE_MODE/DECL_MODE/rtx mode confusion you pointed out. >>> { >>> switch (GET_CODE (rtl)) >>> { >>> case CONST_INT: >>> - { >>> - HOST_WIDE_INT val =3D INTVAL (rtl); >>> + if (mode !=3D BLKmode) >>> + { >>> + gcc_checking_assert (SCALAR_INT_MODE_P (mode)); >>> + HOST_WIDE_INT val =3D INTVAL (rtl); >>> =20 >>> - if (val < 0) >>> - add_AT_int (die, DW_AT_const_value, val); >>> - else >>> - add_AT_unsigned (die, DW_AT_const_value, (unsigned HOST_WIDE_INT) val); >>> - } >>> - return true; >>> + if (val < 0) >>> + add_AT_int (die, DW_AT_const_value, val); >>> + else >>> + add_AT_unsigned (die, DW_AT_const_value, >>> + (unsigned HOST_WIDE_INT) val); >>> + return true; >>> + } This is all a bit html mangled, but this and the other change in loc_descriptor seem to have the effect of doing nothing when called with BLKmode. What is the desired effect of this on the debug information, and how is it achieved? Bernd