>>>>> "Daniel" == Daniel Barlow <dan@...> writes:
Daniel> I have working floating point traps for Alpha now (and have enabled
Daniel> the "find-the-detailed-cause" code in sigfpe-handler, too). But.
Daniel> I'm still failing on the (sqrt single-float-positive-infinity) case.
Daniel> What happens is that -
Daniel> argument is converted to double-float (= double-float-positive-infinity)
Daniel> libm sqrt function is called (= double-float-positive-infinity)
Daniel> result is coerced back to single-float (= SIGFPE)
Daniel> The trap that was set is INVALID-OPERATION. The instruction that
Daniel> generated it is
Daniel> 0x400696b4: cvtts $f4,$f4
Daniel> (ConVerT T to S format, fp register 4)
For what it's worth, CMUCL on Solaris produces this (max speed):
B4: FSTOD %F0, %F0 ; No-arg-parsing entry point
B8: FSQRTD %F0, %F0
BC: FDTOS %F0, %F0
and it doesn't cause an error. (Hmm, make me wonder if the code
should just be fsqrts, but that's a CMUCL issue, not SBCL).
Daniel> My reading of the rather bad scan of IEEE 754 that I seem to have
Daniel> acquired doesn't explicitly say what the result of converting an
Daniel> infinity to a narrower type should be.
I tried to get a copy from Computer Magazine from the local University
library a while back. Some idiot cut out all the pages!