X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=b1d99eb18c08d74954dcb2c1571ad7c3123839ce;hb=1db4f16ef02f5b4d699d78541edb19ad8f3defc8;hp=4c64490f99abbe41f3d21bbdd262e5b923c64aa4;hpb=b4c650bad5478d99132fdf0e219d63cf07d0a5f8;p=sbcl.git diff --git a/BUGS b/BUGS index 4c64490..b1d99eb 100644 --- a/BUGS +++ b/BUGS @@ -479,6 +479,11 @@ WORKAROUND: (print (incf start 22)) (print (incf start 26)))))) + [ Update: 1.0.14.36 improved this quite a bit (20-25%) by + eliminating useless work from PROPAGATE-FROM-SETS -- but as alluded + below, maybe we should be smarter about when to decide a derived + type is "good enough". ] + This example could be solved with clever enough constraint propagation or with SSA, but consider @@ -551,11 +556,6 @@ WORKAROUND: c. The cross-compiler cannot inline functions defined in a non-null lexical environment. -206: ":SB-FLUID feature broken" - (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07) - Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks - the build. - 207: "poorly distributed SXHASH results for compound data" SBCL's SXHASH could probably try a little harder. ANSI: "the intent is that an implementation should make a good-faith @@ -1805,67 +1805,26 @@ WORKAROUND: 419: stack-allocated indirect closure variables are not popped - (locally (declare (optimize speed (safety 0))) (defun bug419 (x) (multiple-value-call #'list (eval '(values 1 2 3)) (let ((x x)) - (declare (dynamic-extent x)) + (declare (sb-int:truly-dynamic-extent x)) (flet ((mget (y) (+ x y)) (mset (z) (incf x z))) (declare (dynamic-extent #'mget #'mset)) - ((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 - - (+ ) ; uses double-precision - (+ (FLOAT )) ; 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? + ((lambda (f g) (eval `(progn ,f ,g (values 4 5 6)))) #'mget #'mset))))) + + (ASSERT (EQUAL (BUG419 42) '(1 2 3 4 5 6))) => failure + + Note: as of SBCL 1.0.26.29 this bug no longer affects user code, as + SB-INT:TRULY-DYNAMIC-EXTENT needs to be used instead of + DYNAMIC-EXTENT for this to happen. Proper fix for this bug requires + (Nikodemus thinks) storing the relevant LAMBDA-VARs in a + :DYNAMIC-EXTENT cleanup, and teaching stack analysis how to deal + with them. 421: READ-CHAR-NO-HANG misbehaviour on Windows Console: @@ -1883,3 +1842,71 @@ Which should be fixed, the IR1, or the backend? behaves ...erratically. Reported by Kevin Reid on sbcl-devel 2007-07-06. (We don't _have_ to check things like this, but we generally try to check returns in safe code, so we should here too.) + +424: toplevel closures and *CHECK-CONSISTENCY* + + The following breaks under COMPILE-FILE if *CHECK-CONSISTENCY* is true. + + (let ((exported-symbols-alist + (loop for symbol being the external-symbols of :cl + collect (cons symbol + (concatenate 'string + "#" + (string-downcase symbol)))))) + (defun hyperdoc-lookup (symbol) + (cdr (assoc symbol exported-symbols-alist)))) + + (Test-case adapted from CL-PPCRE.) + +425: reading from closed streams + + Reported by Damien Cassou on sbcl-devel. REPL transcript follows: + + * (open ".bashrc" :direction :input) + # + * (defparameter *s* *) + *S* + * (read-line *s*) + "# -*- Mode: Sh -*-" + * (read-line *s*) + "# Files you make look like rw-r--r--" + * (open-stream-p *s*) + T + * (close *s*) + T + * (open-stream-p *s*) + NIL + * (read-line *s*) + "umask 022" + + The problem is with the fast path using ansi-stream-cin-buffer not hitting + closed-flame. + +426: inlining failure involving multiple nested calls + + (declaim (inline foo)) + (defun foo (x y) + (cons x y)) + (defun bar (x) + (foo (foo x x) (foo x x))) + ;; shows a full call to FOO + (disassemble 'bar) + ;; simple way to test this programmatically + (let ((code (sb-c::fun-code-header #'bar)) + (foo (sb-impl::fdefinition-object 'foo nil))) + (loop for i from sb-vm:code-constants-offset below (sb-kernel:get-header-data code) + do (assert (not (eq foo (sb-kernel:code-header-ref code i)))))) + + This appears to be an ancient bug, inherited from CMUCL: reportedly + 18c does the same thing. RECOGNIZE-KNOWN-CALL correctly picks up only + one of the calls, but local call analysis fails to inline the call + for the second time. Nikodemus thinks (but is not 100% sure based on + very brief investigation) that the call that is not inlined is the + second nested one. A trivial fix is to call CHANGE-REF-LEAF in known + call for functions already inline converted there, but he is not sure + if this has adverse effects elsewhere. + +428: TIMER SCHEDULE-STRESS in timer.impure.lisp fails + + Failure modes vary. Core problem seems to be (?) recursive entry to + RUN-EXPIRED-TIMERS.