From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80980 invoked by alias); 2 Nov 2015 23:29:08 -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 80966 invoked by uid 89); 2 Nov 2015 23:29:07 -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-11v.sys.comcast.net Received: from resqmta-po-11v.sys.comcast.net (HELO resqmta-po-11v.sys.comcast.net) (96.114.154.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 02 Nov 2015 23:29:06 +0000 Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-11v.sys.comcast.net with comcast id cnUv1r003516pyw01nV5te; Mon, 02 Nov 2015 23:29:05 +0000 Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d]) by resomta-po-08v.sys.comcast.net with comcast id cnV31r00B2ztT3H01nV4zU; Mon, 02 Nov 2015 23:29:04 +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: <871tc8unnx.fsf@e105548-lin.cambridge.arm.com> Date: Mon, 02 Nov 2015 23:29: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> <871tc8unnx.fsf@e105548-lin.cambridge.arm.com> To: Richard Sandiford X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00141.txt.bz2 On Nov 2, 2015, at 12:55 PM, Richard Sandiford = wrote: > This was: >=20 > ... Sometimes structure decls > have BLKmode but are assigned an integer-mode rtl (e.g. when passing > 3-byte structures by value to functions). > [...] > loc_descriptor refuses to use CONST_INT for BLKmode decls (which aren't > actually integers at the source level). That seems like the right > behaviour I=92ll plead ignorance here, but why do you think that? The dwarf standard= says: There are six forms of constants. There are fixed length constant data forms for one, two, four and eight byte values (respec tively, DW_FORM_data1, DW_FORM_data2, DW_FORM_data4, and DW_FORM_data8). There ar e also variable length constant data forms encoded using LEB128 numbers (see below). Both signed (DW_FORM_sdata)= and unsigned (DW_FORM_udata) variable length constants are available The data in DW_FORM_data1, DW _FORM_data2, DW_FORM_data4 and DW_FORM_data8 can be anything. Depending on c ontext, it may be a signed integer, an unsigned integer, a floating-point constant, or anything else. A consumer must use context to know how to interpret the bits, wh ich if they are target machine data (such as an integer or floating point constant) will be in target machine byte-order. Certainly supplying the known byte values of a constant is preferable to th= rowing up our hands and saying, I know, but I=92m not telling. Given the t= ext above, it seems like these forms can be used for content where the comp= iler knows the values of the bits that comprise the content. I=92d ask, is= the backing of your position supported by the dwarf standard? If yes, wha= t part? I think you think that this describes the type, these do not. There is a s= eparate system to describe the type. For example, DW_ATE_UTF describes the= bytes as forming a UTF value. A wide int (or a CONST_INT) can be used to = describe a unicode character, and it would have a DW_ATE_UTF encoding on it= for the debugger to use to formulate an idea of how to display those bytes= . Further, a mythical front end could have a 3 byte unicode character, and= these can be modeless as there is no 3 byte machine mode for them. Code-g= en would be BLKmode, the type would be DW_ATE_UTF, and one could form const= ants with CONST_INT. In a 152 bit UTF character in that front end, CONST_I= NT, generally speaking, isn=92t big enough, so a CONST_WIDE_INT would be fo= rmed. The argument is the same. That a machine has a native 3 byte type = or not, is of no consequence, so _any_ decision based upon the mode in this= way is flawed. Then again, I don=92t even pretend to be a language lawyer= for the dwarf standard. :-)