This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] avoid printing leading 0 in widest_int hex dumps


On 10/19/2017 04:22 PM, Richard Sandiford wrote:
Richard Sandiford <richard.sandiford@linaro.org> writes:
Aldy Hernandez <aldyh@redhat.com> writes:
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.
Ah!  OK.  Yeah, I agree it doesn't make sense to print sign-extension
bits above the precision.  I think it'd work if print_hex used
extract_uhwi insteead of elt, which would also remove the need
to handle "negative" numbers specially.  I'll try that tomorrow.
How about this?  Not tested much beyond the selftests themselves.

Thanks,
Richard


gcc/
	* wide-int-print.cc (print_hex): Loop based on extract_uhwi.
	Don't print any bits outside the precision of the value.
	* wide-int.cc (test_printing): Add some new tests.

This does seem to resolve my printing issues.
THanks

Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]