Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Nov 1995 08:09:20 -0800
From:      Mark Diekhans <markd@grizzly.com>
To:        bde@zeta.org.au
Cc:        bde@zeta.org.au, freebsd-hackers@freebsd.org, jkh@time.cdrom.com, julian@ref.tfs.com
Subject:   Re: NPX still broken in 2.1.0-951104-SNAP...
Message-ID:  <199511061609.IAA08229@Grizzly.COM>
In-Reply-To: <199511060947.UAA10166@godzilla.zeta.org.au> (message from Bruce Evans on Mon, 6 Nov 1995 20:47:43 %2B1100)

next in thread | previous in thread | raw e-mail | index | archive | help
>The ANSI standard says that math functions shall not cause any externally
>visible exceptions; for domain errors, errno shall be set to EDOM and an
>implementation-defined value shall be returned; for range errors, errno
>shall be set to ERANGE and a correctly signed +-HUGE_VAL shall be returned.

So we agree that the current behavior is non-standard.  However you have
convinced me that my suggestion on how to fix it is probably naive.

>What do these systems do for common application errors?  E.g.,

This is the print out ot the result of pow before actualling trying to do
math on the value.  (I don't understand you i387 stack overflow example):

/* 1. Overrun i387 stack. */
SCO: No Error.

/* 2. Overflow. */
SCO: d = inf, e = 34
HPUX: d = 1.79769e+308, e = 34
SGI:  d = inf, e = 34
OSF: d = 1.79769e+308, e = 34, SIGFPE
Ultrix: d = Infinity, e = 34
SUN: d = Inf, e = 34

/* 3. Invalid operation. */
SCO: d = inf, e = 34, SIGFPE
HPUX: d = 1.79769e+308, e = 34
SGI: d = inf, e = 34
OSF: d = 1.79769e+308, e = 34
Ultrix: d = Infinity, e = 34
SUN: d = Inf, e = 34

>Systems that use __IBCS_NPXCW__ for the default control word have to do
>extra work in the library functions so that the library functions don't
>trap.  I think some of the i386 Unixes do this.

Seems a reasonable way to get the behavior.

>The problem is that the control word is global so changing it affects the
>behaviour of d += d and d-= d above as well as fixing the library functions.

I will buy that.  I would total ageee that these non-library function errors
should be trapped if possible, although most system don't seem to do it.


>The correct value isn't passed to __kernel_standard() so one has to be
>invented.  This is fairly easy for acos(|x|>1) because there is only
>one reasonable value (the default NaN).  Other cases are more difficult.
>E.g., for pow(0, negative), the correct value is +HUGE_VAL for +0 and
>-HUGE_VAL for -0 but __kernel_standard always returns -HUGE_VAL.  There
>are 19 different cases for the `IEEE' version of pow(), but only 6 cases
>for pow() in __kernel_standard().

Ok, I am naive.  So how do we get to the point were we don't SIGFPE in
library functions?  Can it at least be made better in the 2.1 time frame?
What can I do to help?


>>----------------------------------------------
>>HP-UX A.09.01:
>>acos: DOMAIN error
>>acos (2.0) = 0, errno = 33
>
>Bogus side effect (extra output).

This is the old SysV matherr stuff.  Applications are suppose to provide
there own matherr function to stop the output (yuk).

Mark



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511061609.IAA08229>