This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ping] Fix PR debug/66728
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Mike Stump <mikestump at comcast dot net>
- Cc: Richard Sandiford <richard dot sandiford at arm dot com>, Bernd Schmidt <bschmidt at redhat dot com>, Ulrich Weigand <uweigand at de dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 5 Nov 2015 13:32:50 +0100
- Subject: Re: [ping] Fix PR debug/66728
- Authentication-results: sourceware.org; auth=none
- References: <20151028115839 dot 1E7C85C3D at oc7340732750 dot ibm dot com> <87ziz3ta4t dot fsf at e105548-lin dot cambridge dot arm dot com> <5630D8AE dot 1090608 at redhat dot com> <87h9l4v2pi dot fsf at e105548-lin dot cambridge dot arm dot com> <87611kuzz4 dot fsf at e105548-lin dot cambridge dot arm dot com> <D9850ADD-F2B9-4B3E-8DD9-DF8FEB2E9C36 at comcast dot net> <871tc8unnx dot fsf at e105548-lin dot cambridge dot arm dot com> <A6732F72-4484-45B8-8232-7B5BF8DE4949 at comcast dot net> <87wptztqpx dot fsf at e105548-lin dot cambridge dot arm dot com> <29C8CB44-A0EC-4A9A-A4D3-3ABB6D66DA5B at comcast dot net> <CAFiYyc18ZRYXJRPYpU0W2vCf8NZQcd8MngHgUb9ggu8HxZ1NKg at mail dot gmail dot com> <7ADD4B03-BF3E-48BA-8028-AC5EB50E773C at comcast dot net> <CAFiYyc2DwthVCAk2TPcTnJOWyCjiuQFGXHKFw08MTNpzGPa9ug at mail dot gmail dot com> <8AEB7496-7440-4239-95E9-272C6EF2AB70 at comcast dot net> <87mvuttrnz dot fsf at e105548-lin dot cambridge dot arm dot com> <721A5B44-82AC-4D72-9E50-500D5E5A7EC5 at comcast dot net>
On Thu, Nov 5, 2015 at 12:45 AM, Mike Stump <mikestump@comcast.net> wrote:
>
> On Nov 4, 2015, at 12:50 PM, Richard Sandiford <richard.sandiford@arm.com> wrote:
>
>> Mike Stump <mikestump@comcast.net> writes:
>>> Index: dwarf2out.c
>>> ===================================================================
>>> --- 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 = std::make_pair (rtl, MAX_MODE_INT);
>>> + int prec = MIN (wi::min_precision (w1, UNSIGNED),
>>> + (unsigned int)CONST_WIDE_INT_NUNITS (rtl) * HOST_BITS_PER_WIDE_INT);
>>> + wide_int w = 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 == *v2->v.val_wide;
>
> Yeah, seems like we should have a v1.prec == 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ât 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 wants to weigh in. I think Iâd 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. Though, maybe the location list versions are never mixed. If they arenât, then there is only 1 client, so, Iâd just do the precision test inline. Anyone able to comment on the location list aspect of this?
No idea on location lists but maybe this means we should just use the
maximum supported integer mode for CONST_WIDE_INTs?