Re: Fix fp-bit.c corner case

[Alan Modra <amodra at bigpond dot net dot au>]

On Fri, Oct 17, 2003 at 09:49:04AM +0200, Andreas Jaeger wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> 
> > This fixes a couple of fp-bit.c corner cases I noticed.  In pack_d, I
> > believe it's possible for rounding to bump the exponent, leading to a
> > NaN being generated rather than Inf.  Moving the exponent overflow check
> > later catches this case.  Note that EXPMAX == 2*EXPBIAS+1 in all fp
> > formats, so testing (exp = src->normal_exp + EXPBIAS) >= EXPMAX is
> > equivalent to testing src->normal_exp > EXPBIAS.
> 
> Do you have any testcase for this that can be added to the testsuite?

Hmm.  In the process of trying to generate a testcase, I retract the
claim that it's possible to bump the exponent in a way that generates a
NaN (*).  The saving grace is that if adding GARDROUND to fraction
results in fraction >= IMPLICIT_2, then all bits above the bottom
NGARDS are zero except for the IMPLICIT_2 bit.  Net result is a mantissa
of zero, which is what we want for Inf.

(*) At least in the normal case with a fraction that's in the normal
range (ie. < 2.0).  As far as I can tell, all uses of pack_d in fp-bit.c
statisfy this requirement.  You can cheat with __make_dp.  For instance,
the following fails in current mainline, but passes with my patch.  I'll
freely admit that this testcase is a rather weak justification for the
patch.  On the other hand moving the exponent overflow test shouldn't
have any negative effects, and makes pack_d all that more robust.

double a;
double inf = 1.0 / 0.0;

extern double __make_dp (int, unsigned int, int, long long);

int main (void)
{
  a = __make_dp (3, 0, 0x7fe, (1LL << (52+1+8)) + (1LL << (1+8)));
  return a != inf;
}

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre