This is the mail archive of the
mailing list for the GCC project.
Re: [wide-int] int_traits <tree>
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, Mike Stump <mikestump at comcast dot net>
- Date: Thu, 17 Oct 2013 09:08:28 +0100
- Subject: Re: [wide-int] int_traits <tree>
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LNX dot 2 dot 00 dot 1310161537220 dot 11149 at zhemvz dot fhfr dot qr> <525EB50F dot 2090003 at naturalbridge dot com> <87ppr56on1 dot fsf at talisman dot default> <525EFC33 dot 4010304 at naturalbridge dot com>
Kenneth Zadeck <firstname.lastname@example.org> 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
> 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.