1.0.13.27: commentary on BUG #420

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 4090ef5..f286819 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -1862,3 +1862,58 @@ WORKAROUND:
               ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset))))))
 
   (ASSERT (EQUAL (BUG419) '(1 2 3 4 5 6))) => failure
+
+420: The MISC.556 test from gcl/ansi-tests/misc.lsp fails hard.
+
+In sbcl-1.0.13 on Linux/x86, executing 
+       (FUNCALL
+        (COMPILE NIL
+                 '(LAMBDA (P1 P2)
+                    (DECLARE
+                     (OPTIMIZE (SPEED 1) (SAFETY 0) (DEBUG 0) (SPACE 0))
+                     (TYPE (MEMBER 8174.8604) P1) (TYPE (MEMBER -95195347) P2))
+                    (FLOOR P1 P2)))
+        8174.8604 -95195347)
+interactively causes
+  SB-SYS:MEMORY-FAULT-ERROR: Unhandled memory fault at #x8.
+The gcl/ansi-tests/doit.lisp program terminates prematurely shortly after
+MISC.556 by falling into gdb with
+  fatal error encountered in SBCL pid 2827: Unhandled SIGILL
+unless the MISC.556 test is commented out.
+
+Analysis: + and a number of other arithmetic functions exhibit the
+same behaviour. Here's the underlying problem: On x86 we perform
+single-float + integer normally using double-precision, and then
+coerce the result back to single-float. (The FILD instruction always
+gives us a double-float, and unless we do MOVE-FROM-SINGLE it remains
+one. Or so it seems to me, and that would also explain the observed
+behaviour below.)
+
+During IR1 we derive the types for both
+
+ (+ <single> <integer>)                   ; uses double-precision
+ (+ <single> (FLOAT <integer> <single>))  ; uses single-precision
+
+and get a mismatch for a number of unlucky arguments. This leads to
+derived result type NIL, and ends up flushing the whole whole
+operation -- and finally we generate code without a return sequence,
+and fall through to whatever.
+
+The use of double-precision in the first case appears to be an
+(un)happy accident -- interval arithmetic gives us the
+double-precision result because that's what the backend does.
+
+ (+ 8172.0 (coerce -95195347 'single-float)) ; => -9.518717e7
+ (+ 8172.0 -95195347)                        ; => -9.5187176e7
+ (coerce (+ 8172.0 (coerce -95195347 'double-float)) 'single-float)
+                                             ; => -9.5187176e7
+
+Which should be fixed, the IR1, or the backend?
+
+421: READ-CHAR-NO-HANG misbehaviour on Windows Console:
+
+  It seems that on Windows READ-CHAR-NO-HANG hangs if the user
+  has pressed a key, but not yet enter (ie. SYSREAD-MAY-BLOCK-P
+  seems to lie if the OS is buffering input for us on Console.)
+
+  reported by Elliot Slaughter on sbcl-devel 2008/1/10.