And as long as we're wishing, it would be awfully nice if INSPECT could
also report on closures, telling about the values of the bound variables.
+ Currently INSPECT and DESCRIBE do show the values, but showing the
+ names of the bindings would be even nicer.
+
35:
The compiler assumes that any time a function of declared FTYPE
doesn't signal an error, its arguments were of the declared type.
holding... * is not equivalent to T in many cases, such as
(VECTOR *) /= (VECTOR T).
-95:
- The facility for dumping a running Lisp image to disk gets confused
- when run without the PURIFY option, and creates an unnecessarily large
- core file (apparently representing memory usage up to the previous
- high-water mark). Moreover, when the file is loaded, it confuses the
- GC, so that thereafter memory usage can never be reduced below that
- level.
-
- (As of 0.8.7.3 it's likely that the latter half of this bug is fixed.
- The interaction between gencgc and the variables used by
- save-lisp-and-die is still nonoptimal, though, so no respite from
- big core files yet)
-
98:
In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
CL), out-of-line structure slot setters are horribly inefficient
(1+ *faa*))
(faa 1d0) => type error
-278:
- a.
- (defun foo ()
- (declare (optimize speed))
- (loop for i of-type (integer 0) from 0 by 2 below 10
- collect i))
-
- uses generic arithmetic.
-
- b. (fixed in 0.8.3.6)
-
279: type propagation error -- correctly inferred type goes astray?
In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
around the same time regarding a call to LIST on sparc with 1000
arguments) and other implementation limit constants.
-311: "Tokeniser not thread-safe"
- (see also Robert Marlow sbcl-help "Multi threaded read chucking a
- spak" 2004-04-19)
- The tokenizer's use of *read-buffer* and *read-buffer-length* causes
- spurious errors should two threads attempt to tokenise at the same
- time.
-
314: "LOOP :INITIALLY clauses and scope of initializers"
reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
test suite, originally by Thomas F. Burdick.
#(1 2 ((SB-IMPL::|,|) + 2 2) 4)
which probably isn't intentional.
-323: "REPLACE, BIT-BASH and large strings"
- The transform for REPLACE on simple-base-strings uses BIT-BASH, which
- at present has an upper limit in size. Consequently, in sbcl-0.8.10
- (defun foo ()
- (declare (optimize speed (safety 1)))
- (let ((x (make-string 140000000))
- (y (make-string 140000000)))
- (length (replace x y))))
- (foo)
- gives
- debugger invoked on a TYPE-ERROR in thread 2412:
- The value 1120000000 is not of type (MOD 536870911).
- (see also "more and better sequence transforms" sbcl-devel 2004-05-10)
-
324: "STREAMs and :ELEMENT-TYPE with large bytesize"
In theory, (open foo :element-type '(unsigned-byte <x>)) should work
for all positive integral <x>. At present, it only works for <x> up
method is applicable, and yet matches neither of the method group
qualifier patterns.
-341: PPRINT-LOGICAL-BLOCK / PPRINT-FILL / PPRINT-LINEAR sharing detection.
- (from Paul Dietz' test suite)
-
- CLHS on PPRINT-LINEAR and PPRINT-FILL (and PPRINT-TABULAR, though
- that's slightly different) states that these functions perform
- circular and shared structure detection on their object. Therefore,
-
- a.(let ((*print-circle* t))
- (pprint-linear *standard-output* (let ((x '(a))) (list x x))))
- should print "(#1=(A) #1#)"
-
- b.(let ((*print-circle* t))
- (pprint-linear *standard-output*
- (let ((x (cons nil nil))) (setf (cdr x) x) x)))
- should print "#1=(NIL . #1#)"
-
- (it is likely that the fault lies in PPRINT-LOGICAL-BLOCK, as
- suggested by the suggested implementation of PPRINT-TABULAR)
-
343: MOP:COMPUTE-DISCRIMINATING-FUNCTION overriding causes error
Even the simplest possible overriding of
COMPUTE-DISCRIMINATING-FUNCTION, suggested in the PCL implementation
#.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
disabled on Darwin for now.
-374: BIT-AND problem on ppc/darwin:
- The BIT-AND test in bit-vector.impure-cload.lisp results in
- fatal error encountered in SBCL pid 8356:
- GC invariant lost, file "gc-common.c", line 605
- on ppc/darwin. Test disabled for the duration.
-
375: MISC.555
(compile nil '(lambda (p1)
(declare (optimize (speed 1) (safety 2) (debug 2) (space 0))
Similar problems exist with SIMPLE-ARRAY-P, ARRAY-HEADER accessors
and all array dimension functions.
+
+383: ASH'ing non-constant zeros
+ Compiling
+ (lambda (b)
+ (declare (type (integer -2 14) b))
+ (declare (ignorable b))
+ (ash (imagpart b) 57))
+ on PPC (and other platforms, presumably) gives an error during the
+ emission of FASH-ASH-LEFT/FIXNUM=>FIXNUM as the assembler attempts to
+ stuff a too-large constant into the immediate field of a PPC
+ instruction. Either the VOP should be fixed or the compiler should be
+ taught how to transform this case away, paying particular attention
+ to side-effects that might occur in the arguments to ASH.
+
+384: Compiler runaway on very large character types
+
+ (compile nil '(lambda (x)
+ (declare (type (member #\a 1) x))
+ (the (member 1 nil) x)))
+
+ The types apparently normalize into a very large type, and the compiler
+ gets lost in REMOVE-DUPLICATES. Perhaps the latter should use
+ a better algorithm (one based on hash tables, say) on very long lists
+ when :TEST has its default value?
+
+ A simpler example:
+
+ (compile nil '(lambda (x) (the (not (eql #\a)) x)))
+
+ (partially fixed in 0.9.3.1, but a better representation for these
+ types is needed.)
+
+385:
+ (format nil "~4,1F" 0.001) => "0.00" (should be " 0.0");
+ (format nil "~4,1@F" 0.001) => "+.00" (should be "+0.0").
+
+386: SunOS/x86 stack exhaustion handling broken
+ According to <http://alfa.s145.xrea.com/sbcl/solaris-x86.html>, the
+ stack exhaustion checking (implemented with a write-protected guard
+ page) does not work on SunOS/x86.
+
+387:
+ 12:10 < jsnell> the package-lock test is basically due to a change in the test
+ behaviour when you install a handler for error around it. I
+ thought I'd disabled the test for now, but apparently that was
+ my imagination
+ 12:19 < Xophe> jsnell: ah, I see the problem in the package-locks stuff
+ 12:19 < Xophe> it's the same problem as we had with compiler-error conditions
+ 12:19 < Xophe> the thing that's signalled up and down the stack is a subtype of
+ ERROR, where it probably shouldn't be
+
+388:
+ (found by Dmitry Bogomolov)
+
+ (defclass foo () ((x :type (unsigned-byte 8))))
+ (defclass bar () ((x :type symbol)))
+ (defclass baz (foo bar) ())
+
+ causes error
+
+ SB-PCL::SPECIALIZER-APPLICABLE-USING-TYPE-P cannot handle the second argument
+ (UNSIGNED-BYTE 8).
+
+389:
+ (reported several times on sbcl-devel, by Rick Taube, Brian Rowe and
+ others)
+
+ ROUND-NUMERIC-BOUND assumes that float types always have a FORMAT
+ specifying whether they're SINGLE or DOUBLE. This is true for types
+ computed by the type system itself, but the compiler type derivation
+ short-circuits this and constructs non-canonical types. A temporary
+ fix was made to ROUND-NUMERIC-BOUND for the sbcl-0.9.6 release, but
+ the right fix is to remove the abstraction violation in the
+ compiler's type deriver.
+
+392: slot-accessor for subclass misses obsoleted superclass
+ (fixed in sbcl-0.9.7.9)
+
+393: Wrong error from methodless generic function
+ (DEFGENERIC FOO (X))
+ (FOO 1 2)
+ gives NO-APPLICABLE-METHOD rather than an argument count error.
+
+394: (SETF CLASS-NAME)/REINITIALIZE-INSTANCE bug
+ (found by PFD ansi-tests)
+ in sbcl-0.9.7.15, (SETF (CLASS-NAME <class>) 'NIL) causes
+ (FIND-CLASS NIL) to return a #<STANDARD-CLASS NIL>.