Date: Tue, 7 Nov 1995 07:05:22 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, markd@grizzly.com Cc: 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: <199511062005.HAA29871@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>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): The stack overflow example calls a function that is implicitly declared as returning int but which actually returns double. If double results are returned on the i387 stack, then they probably won't be removed (the actual behaviour is undefined), so the stack will overflow after about 8 calls. >/* 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 When did the SIGFPE occur? >>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. I tried masking overflow and division by 0, leaving only invalid operand exceptions unmasked. This works quite well for detecting bugs without breaking things that IEEE arithmetic can do well: pow(0.0, -1.0) = Inf; int i = pow(0.0, -1.0) => SIGFPE stack overflow => SIGFPE acos(2.0) => SIGFPE (oops) If acos(2.0) didn't trap and wasn't messed up by __kernel_standard(), then it would return a quiet NaN which wouldn't cause any more SIGFPEs. >>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 >>... >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? I don't see how it can be fixed for 2.1 unless 2.1 slips for another month or two. To stop exceptions in library math functions, the exception mask would have to be changed for each function. There are already wrapper functions that make this easier. There are 50 wrapper functions :-(. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511062005.HAA29871>