On 08/28/2013 03:45 AM, Richard Biener wrote:
On Tue, 27 Aug 2013, Kenneth Zadeck wrote:
removed all knowledge of SHIFT_COUNT_TRUNCATED from wide-int
both Richard Biener and Richard Sandiford had commented negatively about
this.
fixed bug with wide-int::fits_uhwi_p.
inline bool
wide_int_ro::fits_uhwi_p () const
{
- return (len == 1 && val[0] >= 0) || (len == 2 && val[1] == 0);
+ return (precision <= HOST_BITS_PER_WIDE_INT)
+ || (len == 1 && val[0] >= 0)
+ || (len == 2 && (precision >= 2 * HOST_BITS_PER_WIDE_INT) && (val[1]
==
0))
+ || (len == 2 && (sext_hwi (val[1], precision &
(HOST_BITS_PER_WIDE_INT
- 1)) == 0));
}
it now get's scary ;) Still wrong for precision == 0?
no, because anything that comes in at precision 0 is a canonized sign
extended number already. the precision 0 just means that it is safe to
be any precision.
;)
I wonder what it's semantic is ... in double_int we simply require
high == 0 (thus, negative numbers are not allowed). with
precision <= HOST_BITS_PER_WIDE_INT you allow negative numbers.
Matching what double-int fits_uhwi does would be
(len == 1 && ((signed HOST_WIDE_INT)val[0]) >= 0)
it is signed so i am matching this part.
|| (len == 2 && val[1] == 0)
so this does not work. say i had a precision 70 bit wide-int. The bits
above the precision are undefined, so i have to clear it out. This is
what the two lines at len 2 are for. However if the precision is
greater than 2 hwi's then we can do something this simple.
kenny
(I don't remember off-hand the signedness of val[], but eventually
you missed the conversion to signed)
Now, what double-int does is supposed to match
host_integerp (..., 1) which I think it does.
Richard.
