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?
;)
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)
|| (len == 2 && val[1] == 0)
(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.
