This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: math-emu issue with fp divide


From: Kumar Gala <galak@kernel.crashing.org>
Date: Thu, 5 Jun 2008 08:38:44 -0500 (CDT)

> Now that I'm digging into this a bit I'm thinking my issue has to do with
> the fix you put in place from back in Aug 2007 (commit
> 405849610fd96b4f34cd1875c4c033228fea6c0f):
> 
> [MATH-EMU]: Fix underflow exception reporting.
> 
>     2) we ended up rounding back up to normal (this is the case where
>        we set the exponent to 1 and set the fraction to zero), this
>        should set inexact too
> ...
> 
>     Another example, "0x0.0000000000001p-1022 / 16.0", should signal both
>     inexact and underflow.  The cpu implementations and ieee1754
>     literature is very clear about this.  This is case #2 above.
> 
> I'm not clear from your commit comment on what actual number
> 0x0.0....01p-1022 is?

I haven't been able to look closely at this yet but I think I
happened to stumble over the test case that lead me to that
changeset you are referencing here.

The "actual number" is exactly as listed "0x0.0000000000001p-1022",
I don't know what's so confusing about it :-)))

I think this was distilled by Jakub Jelinek from some glibc test case.

#include <float.h>
#include <fenv.h>
#include <stdio.h>

volatile double d = DBL_MIN;
volatile double e = 0x0.0000000000001p-1022;
volatile double f = 16.0;
int
main (void)
{
  printf ("%x\n", fetestexcept (FE_UNDERFLOW));
  d /= f;
  printf ("%x\n", fetestexcept (FE_UNDERFLOW));
  e /= f;
  printf ("%x\n", fetestexcept (FE_UNDERFLOW));
  return 0;
}


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