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 branch updated.


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.


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