(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
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
3: (SB-C::BOUND-FUNC ...)
4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
+ These are now fixed, but (COERCE HUGE 'SINGLE-FLOAT) still signals a
+ type-error at runtime. The question is, should it instead signal a
+ floating-point overflow, or return an infinity?
+
408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
(aver (equal (multiple-value-list
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
-
- (+ <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?
+ ((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:
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.)
+
+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.