On Wed, 31 Oct 2018, Rajalakshmi Srinivasaraghavan wrote:

> On 10/25/2018 09:40 PM, Joseph Myers wrote:
> > On Thu, 25 Oct 2018, Rajalakshmi Srinivasaraghavan wrote:
> > 
> > > +  if (__builtin_unpack_longdouble (a, 0) < TWO53)
> > > +    {
> > > +      /* In this case the integer portion is completely contained
> > > +         within the high double.  So use the hardware convert to
> > > +         integer doubleword, and then extend to int.  */
> > > +      l1 = __builtin_unpack_longdouble (a, 0);
> > > +      result = l1;
> > 
> > But if the high double is a positive integer, and the low double is
> > strictly negative (not -0), you need to subtract 1 to get a result that's
> > correctly truncated towards zero.
> 
> Do you suggest like this?
> 
> if (__builtin_unpack_longdouble (a, 0) < TWO53)
>   {
>     l1 = __builtin_unpack_longdouble (a, 0);
>     if (__builtin_unpack_longdouble (a, 1) < 0.0)
>       result = l1 - 1;
>     else
>       result = l1;
>   }

Yes, but there's another case to consider as well.

As I understand it, this part of the code also applies when the IBM long 
double value is negative.  If that value is <= -1, the code is fine 
regardless of any adjustment for the low part (the result of the 
conversion is unspecified, with INVALID exception).  But you also need to 
consider:

* High part equal to -1, and low part positive.  In that case you must 
produce an integer result of 0, with no INVALID exception.

* High part in open interval (-1, 0).  In that case, regardless of the low 
part, you must produce an integer result of 0, with no INVALID exception - 
you must not adjust an intermediate result of 0 (from converting the high 
part to integer) into one of -1 - so subtracting 1 based on the low part 
being negative, without regard to whether the high part is also negative, 
isn't correct.

I strongly advise adding tests to the testsuite covering all these cases 
and the various cases in the code (some may be covered by the existing 
gcc.dg/torture/fp-int-convert* tests, but those are generic rather than 
aimed at the peculiarities of IBM long double).

-- 
Joseph S. Myers
jos...@codesourcery.com

Reply via email to