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/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.

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


Andrew


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