Re: [Sbcl-devel] More floating point

[Raymond T. <to...@rt...>]

>>>>> "Daniel" == Daniel Barlow <da...@te...> 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!

Ray