[patch] avoid printing leading 0 in widest_int hex dumps

[Richard Sandiford]

Andrew MacLeod <amacleod@redhat.com> writes:
> On 10/17/2017 08:18 AM, Richard Sandiford wrote:
>> Aldy Hernandez <aldyh@redhat.com> writes:
>>> Hi folks!
>>>
>>> Calling print_hex() on a widest_int with the most significant bit turned
>>> on can lead to a leading zero being printed (0x0ffff....). This produces
>>> confusing dumps to say the least, especially when you incorrectly assume
>>> an integer is NOT signed :).
>> That's the intended behaviour though.  wide_int-based types only use as
>> many HWIs as they need to store their current value, with any other bits
>> in the value being a sign extension of the top bit.  So if the most
>> significant HWI in a widest_int is zero, that HWI is there to say that
>> the previous HWI should be zero- rather than sign-extended.
>>
>> So:
>>
>>     0x0ffffffff  -> (1 << 32) - 1 to infinite precision
>> 		   (i.e. a positive value)
>>     0xffffffff   -> -1
>>
>> Thanks,
>> Richard
>
> I for one find this very confusing.  If I have a 128 bit value, I don't 
> expect to see a 132 bits.  And there are enough 0's its not obvious when 
> I look.

But Aldy was talking about widest_int, which is wider than 128 bits.
It's an approximation of infinite precision.

wide_int is the type to use if you want an N-bit number (for some N).

> I don't think a leading 0 should be printed if "precision" bits have 
> already been printed.

Does 0 get printed in that case though?  Aldy's patch skips an upper
HWI if the upper HWI is zero, but we never have more HWIs than the
number that's being represented.

Thanks,
Richard