From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50858 invoked by alias); 5 Nov 2015 12:32:55 -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 50838 invoked by uid 89); 5 Nov 2015 12:32:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f173.google.com Received: from mail-yk0-f173.google.com (HELO mail-yk0-f173.google.com) (209.85.160.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 05 Nov 2015 12:32:53 +0000 Received: by ykba4 with SMTP id a4so127229082ykb.3 for ; Thu, 05 Nov 2015 04:32:51 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.125.194 with SMTP id y185mr5691189ywc.5.1446726771196; Thu, 05 Nov 2015 04:32:51 -0800 (PST) Received: by 10.37.93.11 with HTTP; Thu, 5 Nov 2015 04:32:50 -0800 (PST) In-Reply-To: <721A5B44-82AC-4D72-9E50-500D5E5A7EC5@comcast.net> 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> <87wptztqpx.fsf@e105548-lin.cambridge.arm.com> <29C8CB44-A0EC-4A9A-A4D3-3ABB6D66DA5B@comcast.net> <7ADD4B03-BF3E-48BA-8028-AC5EB50E773C@comcast.net> <8AEB7496-7440-4239-95E9-272C6EF2AB70@comcast.net> <87mvuttrnz.fsf@e105548-lin.cambridge.arm.com> <721A5B44-82AC-4D72-9E50-500D5E5A7EC5@comcast.net> Date: Thu, 05 Nov 2015 12:32:00 -0000 Message-ID: Subject: Re: [ping] Fix PR debug/66728 From: Richard Biener To: Mike Stump Cc: Richard Sandiford , Bernd Schmidt , Ulrich Weigand , GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00457.txt.bz2 On Thu, Nov 5, 2015 at 12:45 AM, Mike Stump wrote: > > On Nov 4, 2015, at 12:50 PM, Richard Sandiford wrote: > >> Mike Stump writes: >>> Index: dwarf2out.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- dwarf2out.c (revision 229720) >>> +++ dwarf2out.c (working copy) >>> @@ -15593,8 +15593,13 @@ >>> return true; >>> >>> case CONST_WIDE_INT: >>> - add_AT_wide (die, DW_AT_const_value, >>> - std::make_pair (rtl, GET_MODE (rtl))); >>> + { >>> + wide_int w1 =3D std::make_pair (rtl, MAX_MODE_INT); >>> + int prec =3D MIN (wi::min_precision (w1, UNSIGNED), >>> + (unsigned int)CONST_WIDE_INT_NUNITS (rtl) * HOST_B= ITS_PER_WIDE_INT); >>> + wide_int w =3D wide_int::from (w1, prec, UNSIGNED); >>> + add_AT_wide (die, DW_AT_const_value, w); >>> + } >>> return true; >>> >>> case CONST_DOUBLE: >> >> Setting the precision based on CONST_WIDE_INT_NUNITS means that >> we might end up with two different precisions for two values of >> the same variable. E.g. for a 192-bit type, 1<<64 would be given >> a precision of 128 (because it needs two HWIs to store) but 1<<128 >> would be given a precision of 192 (because it needs three HWIs to store). >> We could then abort when comparing them for equality, since equality >> needs both integers to have the same precision. E.g. from same_dw_val_p: >> >> case dw_val_class_wide_int: >> return *v1->v.val_wide =3D=3D *v2->v.val_wide; > > Yeah, seems like we should have a v1.prec =3D=3D v2.prec && on that. The= bad news, there are four of them that are like this. The good news, 3 of = them are location operands, and I don=E2=80=99t think they can hit for a ve= ry long time. I think this is an oversight from the double_int version of = the code where we just check the 128 bits for equality. We can see if Rich= ard wants to weigh in. I think I=E2=80=99d just pre-approve the change, th= ough, I think a helper to perform mixed equality testing would be the way t= o go as there are 4 of them, and I pretty sure they should all use the mixe= d version. Though, maybe the location list versions are never mixed. If t= hey aren=E2=80=99t, then there is only 1 client, so, I=E2=80=99d just do th= e precision test inline. Anyone able to comment on the location list aspec= t of this? No idea on location lists but maybe this means we should just use the maximum supported integer mode for CONST_WIDE_INTs?