From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94342 invoked by alias); 4 Nov 2015 23:45: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 94327 invoked by uid 89); 4 Nov 2015 23:45:57 -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-04v.sys.comcast.net Received: from resqmta-po-04v.sys.comcast.net (HELO resqmta-po-04v.sys.comcast.net) (96.114.154.163) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 04 Nov 2015 23:45:56 +0000 Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-04v.sys.comcast.net with comcast id dblu1r0044xDoy801bluTX; Wed, 04 Nov 2015 23:45:54 +0000 Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d]) by resomta-po-05v.sys.comcast.net with comcast id dblt1r0062ztT3H01bltAP; Wed, 04 Nov 2015 23:45:54 +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: <87mvuttrnz.fsf@e105548-lin.cambridge.arm.com> Date: Wed, 04 Nov 2015 23:45:00 -0000 Cc: Richard Biener , Bernd Schmidt , Ulrich Weigand , GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Richard Sandiford X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00409.txt.bz2 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; >>=20 >> 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_BITS_PER_WIDE_INT); >> + wide_int w =3D wide_int::from (w1, prec, UNSIGNED); >> + add_AT_wide (die, DW_AT_const_value, w); >> + } >> return true; >>=20 >> case CONST_DOUBLE: >=20 > 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: >=20 > 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 b= ad news, there are four of them that are like this. The good news, 3 of th= em are location operands, and I don=92t think they can hit for a very 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 Richard want= s to weigh in. I think I=92d just pre-approve the change, though, I think = a helper to perform mixed equality testing would be the way to go as there = are 4 of them, and I pretty sure they should all use the mixed version. Th= ough, maybe the location list versions are never mixed. If they aren=92t, = then there is only 1 client, so, I=92d just do the precision test inline. = Anyone able to comment on the location list aspect of this?