Kenneth Zadeck <zad...@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
