From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32430 invoked by alias); 3 Nov 2015 08:46:58 -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 30682 invoked by uid 89); 3 Nov 2015 08:46:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Nov 2015 08:46:55 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-34-H0-AOCXPS6KEB7jv5ALPtg-1; Tue, 03 Nov 2015 08:46:50 +0000 Received: from localhost ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2015 08:46:50 +0000 From: Richard Sandiford To: Mike Stump Mail-Followup-To: Mike Stump ,Bernd Schmidt , Ulrich Weigand , , richard.sandiford@arm.com Cc: Bernd Schmidt , Ulrich Weigand , Subject: Re: [ping] Fix PR debug/66728 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> Date: Tue, 03 Nov 2015 08:46:00 -0000 In-Reply-To: (Mike Stump's message of "Mon, 2 Nov 2015 15:28:19 -0800") Message-ID: <87wptztqpx.fsf@e105548-lin.cambridge.arm.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-MC-Unique: H0-AOCXPS6KEB7jv5ALPtg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-11/txt/msg00165.txt.bz2 Mike Stump writes: > 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=E2=80=99ll 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_sdat= a) 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 > throwing up our hands and saying, I know, but I=E2=80=99m not telling. G= iven > the text above, it seems like these forms can be used for content where > the compiler knows the values of the bits that comprise the content. > I=E2=80=99d ask, is the backing of your position supported by the dwarf > standard? If yes, what part? > > I think you think that this describes the type, these do not. There is > a separate 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-gen would be BLKmode, the type would > be DW_ATE_UTF, and one could form constants with CONST_INT. In a 152 > bit UTF character in that front end, CONST_INT, generally speaking, > isn=E2=80=99t big enough, so a CONST_WIDE_INT would be formed. The argum= ent 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. This isn't just an argument about the DWARF standard though. It's an argument about GCC internals. Presumably these hypothetical BLKmode types would need to support addition, but plus:BLK is not well formed, and wouldn't distinguish between your 3-byte and 152-bit cases. I don't think const_int and const_wide_int are logically different. There's the historical decision that const_int doesn't have a stored mode, but I don't think that was because we wanted to support const_ints that are conceptually BLKmode. I think from an rtl perspective the only sensible way for frontends to cope with integers whose size doesn't match an rtl mode is to promote to the next widest mode, which is what the stor-layout.c code I quoted does. Obviously if your 3 byte type is actually 3 bytes in memory rather than 4, and no 3-byte mode is available, you can't just load and store the value using a normal rtl move. You have to use bitfield extraction and insertion instead. I picked this PR up because it was wide-int-related, even though (as is probably all too obvious from this thread) I'm not familiar with the dwarf2out.c code. It's actually your commit that I'm trying to fix here (r201707). Would you mind taking the PR over and handling it the way you think it should be handled? Thanks, Richard