On Tue, Oct 17, 2017 at 6:05 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
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.
IMO, we should document this leading zero in print_hex, as it's not
inherently obvious.
But yes, I was talking about widest_int. I should explain what I am
trying to accomplish, since perhaps there is a better way.
I am printing a a wide_int (bounds[i] below), but I really don't want
to print the sign extension nonsense, since it's a detail of the
underlying representation.