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
419: stack-allocated indirect closure variables are not popped
- (locally (declare (optimize speed (safety 0)))
+ (locally (declare (optimize sb-c::stack-allocate-dynamic-extent
+ sb-c::stack-allocate-value-cells))
(defun bug419 (x)
(multiple-value-call #'list
(eval '(values 1 2 3))
(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
+ (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-C::STACK-ALLOCATE-VALUE-CELLS needs to be explicitly turned on for
+ that 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.
420: The MISC.556 test from gcl/ansi-tests/misc.lsp fails hard.
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.
+
+427: ANY-REG not good for primitive type T
+
+ ...which is true, of course, but the following should not complain
+ about it (on x86 and x86-64):
+
+ (sb-alien:with-alien ((buf (array (sb-alien:signed 8) 16))))
+
+ reported by Stelian Ionescu on sbcl-devel.
+