On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
> 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.
Hmm, how can "any" precision be valid? Only any precision that can
represent the value. fits_uhwi_p asks whether truncation to
hwi precision is value-preserving.
> > ;)
> >
> > 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.
? The bits in the encoding should not be undefined. And why should
they be magically defined when the precision is greater than 2 hwi's then?
Richard.
