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: [wide-int] int_traits <tree>


Kenneth Zadeck <zadeck@naturalbridge.com> writes:
>> As mentioned in my message yesterday, I thought your new way of canonising
>> unsigned tree constants meant that there was always an upper zero bit.
>> Is that right?
> i believe this is correct.
>> If so, xprecision < precision is a no-op, because the number always
>> has the right form for wider precisions.  The only difficult case is
>> xprecision == precision, since then we need to peel off any upper -1 HWIs.
> say my HWI size is 8 bits (just to keep from typing a million 'f's.   if 
> i have a 16 bit unsigned number that is all 1s in the tree world it is 3 
> hwis
> 0x00 0xff 0xff.
>
> but inside regular wide int, it would take 1 wide int whose value is 0xff.
> inside of max it would be the same as the tree, but then the test 
> precision < xprecision + hbpwi never kicks in because precision is 
> guaranteed to be huge.
>
> inside of addr_wide_int, i think we tank with the assertion.

It should be OK for addr_wide_int too.  The precision still fits 2 HWIs.
The initial length is greater than the maximum length of an addr_wide_int,
but your "len = MAX (len, max_len)" deals with that.

> the case actually comes up on the ppc because they do a lot of 128 bit 
> math.    I think i got thru the x86-64 without noticing this.

Well, it'd be suspicious if we're directly using 128-bit numbers
in addr_wide_int.  The justification for the assertion was that we
should explicitly truncate to addr_wide_int when deliberately
ignoring upper bits, beyond bit or byte address width.  128 bits
definitely falls into that category on powerpc.

Thanks,
Richard


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