From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17591 invoked by alias); 2 Nov 2015 20:55:22 -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 17578 invoked by uid 89); 2 Nov 2015 20:55:21 -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; Mon, 02 Nov 2015 20:55:19 +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-24-yNl2pVRrQfuLInVS70i3pw-1; Mon, 02 Nov 2015 20:55:14 +0000 Received: from localhost ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2015 20:55:14 +0000 From: Richard Sandiford To: Mike Stump Mail-Followup-To: Mike Stump ,Bernd Schmidt , Ulrich Weigand , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Cc: Bernd Schmidt , Ulrich Weigand , gcc-patches@gcc.gnu.org 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> Date: Mon, 02 Nov 2015 20:55:00 -0000 In-Reply-To: (Mike Stump's message of "Mon, 2 Nov 2015 12:33:48 -0800") Message-ID: <871tc8unnx.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: yNl2pVRrQfuLInVS70i3pw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-11/txt/msg00124.txt.bz2 Mike Stump writes: > On Nov 2, 2015, at 8:29 AM, Richard Sandiford = wrote: >> 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=E2=80=99t see this discuss= ed. I > didn=E2=80=99t see a test case? I=E2=80=99d like to think that BLKmode t= hings here > would be fine. I think they would be use for 1024 bit things that are > representable in 20 bits, for example. This was: ... 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, so this patch does that for add_const_value_attribute too. It asserts that the mode is otherwise sensible for both CONST_INT and CONST_WIDE_INT. Asserting for CONST_INT isn't strictly necessary but means that the assumption will get much more coverage than asserting only for CONST_WIDE_INT does. Integer types always have an integer mode, not BLKmode. E.g. layout_type has: case BOOLEAN_TYPE: case INTEGER_TYPE: case ENUMERAL_TYPE: SET_TYPE_MODE (type, smallest_mode_for_size (TYPE_PRECISION (type), MODE_INT)); where the smallest_mode_for_size is guaranteed to return something that isn't BLKmode (or VOIDmode). The BLKmodes are for non-integer things that nevertheless get passed as integers. I don't think debuggers would be expecting an integer DIE to be used for them. (loc_descriptor already punts in that case.) > 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 > precision won=E2=80=99t be 0 and the existing code will work. Where is t= he 0 > first generated, and from what? It's generated from: case CONST_WIDE_INT: add_AT_wide (die, DW_AT_const_value, std::make_pair (rtl, GET_MODE (rtl))); return true; where the precision is evaluated as: inline unsigned int wi::int_traits ::get_precision (const rtx_mode_t &x) { return GET_MODE_PRECISION (x.second); } GET_MODE (rtl) is always VOIDmode and the precision of VOIDmode is 0, so the precision of the wide_int passed to add_AT_wide is always 0. Like CONST_INT, the "real" mode of a CONST_WIDE_INT is determined by context rather than being stored in the rtx itself. The point of the patch is to use that mode instead of VOIDmode in the make_pair. Thanks, Richard