From owner-freebsd-hackers Mon Nov 6 08:19:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA00585 for hackers-outgoing; Mon, 6 Nov 1995 08:19:54 -0800 Received: from cats.ucsc.edu (root@cats-po-1.UCSC.EDU [128.114.129.22]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA00579 for ; Mon, 6 Nov 1995 08:19:52 -0800 Received: from scruz.ucsc.edu by cats.ucsc.edu with SMTP id IAA04577; Mon, 6 Nov 1995 08:19:35 -0800 Received: from osprey by scruz.ucsc.edu id aa08219; 6 Nov 95 8:17 PST Received: (from markd@localhost) by Grizzly.COM (8.6.9/8.6.9) id IAA08229; Mon, 6 Nov 1995 08:09:20 -0800 Date: Mon, 6 Nov 1995 08:09:20 -0800 From: Mark Diekhans Message-Id: <199511061609.IAA08229@Grizzly.COM> To: bde@zeta.org.au CC: bde@zeta.org.au, freebsd-hackers@freebsd.org, jkh@time.cdrom.com, julian@ref.tfs.com In-reply-to: <199511060947.UAA10166@godzilla.zeta.org.au> (message from Bruce Evans on Mon, 6 Nov 1995 20:47:43 +1100) Subject: Re: NPX still broken in 2.1.0-951104-SNAP... Sender: owner-hackers@freebsd.org Precedence: bulk >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