From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116798 invoked by alias); 2 Nov 2015 20:34:38 -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 116784 invoked by uid 89); 2 Nov 2015 20:34:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: resqmta-po-08v.sys.comcast.net Received: from resqmta-po-08v.sys.comcast.net (HELO resqmta-po-08v.sys.comcast.net) (96.114.154.167) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 02 Nov 2015 20:34:36 +0000 Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-08v.sys.comcast.net with comcast id ckZB1r00956HXL001kaal1; Mon, 02 Nov 2015 20:34:34 +0000 Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d]) by resomta-po-12v.sys.comcast.net with comcast id ckaX1r00V2ztT3H01kaZQJ; Mon, 02 Nov 2015 20:34:34 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [ping] Fix PR debug/66728 From: Mike Stump In-Reply-To: <87611kuzz4.fsf@e105548-lin.cambridge.arm.com> Date: Mon, 02 Nov 2015 20:34:00 -0000 Cc: Bernd Schmidt , Ulrich Weigand , gcc-patches@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151028115839.1E7C85C3D@oc7340732750.ibm.com> <87ziz3ta4t.fsf@e105548-lin.cambridge.arm.com> <5630D8AE.1090608@redhat.com> <87h9l4v2pi.fsf@e105548-lin.cambridge.arm.com> <87611kuzz4.fsf@e105548-lin.cambridge.arm.com> To: Richard Sandiford X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00122.txt.bz2 On Nov 2, 2015, at 8:29 AM, Richard Sandiford w= rote: > switch (GET_CODE (rtl)) > { > case CONST_INT: > - { > - HOST_WIDE_INT val =3D INTVAL (rtl); > + if (mode !=3D BLKmode) This changes BLKmode for CONST_INT, but I didn=92t see this discussed. I d= idn=92t see a test case? I=92d like to think that BLKmode things here woul= d be fine. I think they would be use for 1024 bit things that are represen= table in 20 bits, for example. A value that is 1 (representable in 20 bits= ) can be trivially communicated the debugger. The existing add_AT_unsigned= I think can represent them, no? Similarly for wide-int BLKmode support. = I think the real problem is simply the precision 0 part. In the CONST_INT = and CONST_DOUBLE there is no code that handled precision 0, and there is no= code in the wide-int case either. From wide-int.h: The precision and length of a wide_int are always greater than 0. If is was 0, then we have failed. When that bug is fixed, then the precisi= on won=92t be 0 and the existing code will work. Where is the 0 first gene= rated, and from what?