(frob-stringwise-foo *stringwise-foo*)
SEGV.
-6:
- bogus warnings about undefined functions for magic functions like
- SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files
- like src/code/float.lisp. Fixing this will probably require
- straightening out enough bootstrap consistency issues that
- the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*.
- Instead, the cross-compiler runs in a slightly flaky state
- which is sane enough to compile SBCL itself, but which is
- also unstable in several ways, including its inability
- to really grok function declarations.
-
- As of sbcl-0.7.5, sbcl's cross-compiler does run with
- *TYPE-SYSTEM-INITIALIZED*; however, this bug remains.
-
7:
The "compiling top-level form:" output ought to be condensed.
Perhaps any number of such consecutive lines ought to turn into a
(FORMAT NIL "~,1G" 1.4) => "1. "
(FORMAT NIL "~3,1G" 1.4) => "1. "
-20:
- from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000:
- (defclass ccc () ())
- (setf (find-class 'ccc1) (find-class 'ccc))
- (defmethod zut ((c ccc1)) 123)
- In sbcl-0.7.1.13, this gives an error,
- There is no class named CCC1.
- DTC's recommended workaround from the mailing list 3 Mar 2000:
- (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
-
27:
Sometimes (SB-EXT:QUIT) fails with
Argh! maximum interrupt nesting depth (4096) exceeded, exiting
45:
a slew of floating-point-related errors reported by Peter Van Eynde
on July 25, 2000:
- b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and
- should probably be 1.4012985e-45. In SBCL,
+ b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT on the x86 is
+ bogus, and should probably be 1.4012985e-45. In SBCL,
(/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
than LEAST-POSITIVE-SHORT-FLOAT. Similar problems
exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
(ADD-METHOD (FUNCTION FOO03) M)))
should give an error, but SBCL allows it.
-52:
- It has been reported (e.g. by Peter Van Eynde) that there are
- several metaobject protocol "errors". (In order to fix them, we might
- need to document exactly what metaobject protocol specification
- we're following -- the current code is just inherited from PCL.)
-
60:
The debugger LIST-LOCATIONS command doesn't work properly.
(partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to
make the temporary filename less easily guessable)
-82:
- Functions are assigned names based on the context in which they're
- defined. This is less than ideal for the functions which are
- used to implement CLOS methods. E.g. the output of
- (DESCRIBE 'PRINT-OBJECT) lists functions like
- #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}>
- and
- #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
- It would be better if these functions' names always identified
- them as methods, and identified their generic functions and
- specializers.
-
83:
RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
expansion, leaving garbage consisting of infinished blocks of the
partially converted function.)
+ (due to reordering of the compiler this example is compiled
+ successfully by 0.7.14, but the bug probably remains)
+
162:
(reported by Robert E. Brown 2002-04-16)
When a function is called with too few arguments, causing the
(INTEGER 1296 1296)
...)>)[:EXTERNAL]
+ In recent SBCL the following example also illustrates this bug:
+
+ (time (compile
+ nil
+ '(lambda ()
+ (declare (optimize (safety 3)))
+ (declare (optimize (compilation-speed 2)))
+ (declare (optimize (speed 1) (debug 1) (space 1)))
+ (let ((start 4))
+ (declare (type (integer 0) start))
+ (print (incf start 22))
+ (print (incf start 26))
+ (print (incf start 28)))
+ (let ((start 6))
+ (declare (type (integer 0) start))
+ (print (incf start 22))
+ (print (incf start 26)))
+ (let ((start 10))
+ (declare (type (integer 0) start))
+ (print (incf start 22))
+ (print (incf start 26))))))
+
190: "PPC/Linux pipe? buffer? bug"
In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
on the PPC/Linux platform, waiting for a zombie env process. This
229:
(subtypep 'function '(function)) => nil, t.
-231: "SETQ does not correctly check the type of a variable being set"
- b.
- (defun foo (x z)
- (declare (type integer x))
- (locally (declare (type (real 1) x))
- (setq x z))
- (list x z))
- (foo 0 0) => (0 0).
-
- (fixed in 0.7.12.8)
-
233: bugs in constraint propagation
a.
(defun foo (x)
(+ x 2)))
(foo 1d0 5) => segmentation violation
-234:
- (fixed in sbcl-0.7.10.36)
-
235: "type system and inline expansion"
a.
(declaim (ftype (function (cons) number) acc))
compiler gets its hands on the code needing compilation from the REPL,
it has been macroexpanded several times.
-239:
- Since 0.7.0:
- (defun foo (bit-array-2 &optional result-bit-array)
- (declare (type (array bit) bit-array-2)
- (type (or (array bit) (member t nil)) result-bit-array))
- (unless (simple-bit-vector-p bit-array-2)
- (multiple-value-call
- (lambda (data1 start1)
- (multiple-value-call
- (lambda (data2 start2)
- (multiple-value-call
- (lambda (data3 start3)
- (declare (ignore start3))
- (print (list data1 data2)))
- (values 0 0)))
- (values bit-array-2 0)))
- (values 444 0))))
-
- Then (foo (make-array 4 :element-type 'bit :adjustable t) nil)
- must return the same value as it prints, but it returns random garbage.
-
-240:
- "confused lexical/special warnings in MULTIPLE-VALUE-BIND"
- (from tonyms on #lisp IRC 2003-02-25)
- In sbcl-0.7.12.55, compiling
- (cl:in-package :cl-user)
- (defvar *foo* 0)
- (defvar *bar* 1)
- (defun bar ()
- (multiple-value-bind (*foo* *bar*) 'eleventy-one
- (bletch)))
- (defun bletch () (format t "~&*FOO*=~S *BAR*=~S" *foo* *bar*))
- (bar)
- gives warnings like "using the lexical binding of the symbol *FOO*"
- even though LOADing the fasl file shows that in fact the special
- bindings are being used.
-
-241:
- "DEFCLASS mysteriously remembers uninterned accessor names."
+ A symptom of the same underlying problem, reported by Tony Martinez:
+ * (handler-case
+ (with-input-from-string (*query-io* " no")
+ (yes-or-no-p))
+ (simple-type-error () 'error))
+ ; in: LAMBDA NIL
+ ; (SB-KERNEL:FLOAT-WAIT)
+ ;
+ ; note: deleting unreachable code
+ ; compilation unit finished
+ ; printed 1 note
+
+241: "DEFCLASS mysteriously remembers uninterned accessor names."
(from tonyms on #lisp IRC 2003-02-25)
In sbcl-0.7.12.55, typing
(defclass foo () ((bar :accessor foo-bar)))
So it's somehow checking the uninterned old accessor name instead
of the new requested accessor name, which seems broken to me (WHN).
+242: "WRITE-SEQUENCE suboptimality"
+ (observed from clx performance)
+ In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type
+ (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
+ (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
+ rather than writing the sequence in one go, leading to severe
+ performance degradation.
+
+243: "STYLE-WARNING overenthusiasm for unused variables"
+ (observed from clx compilation)
+ In sbcl-0.7.14, in the presence of the macros
+ (DEFMACRO FOO (X) `(BAR ,X))
+ (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL)
+ somewhat surprising style warnings are emitted for
+ (COMPILE NIL '(LAMBDA (Y) (FOO Y))):
+ ; in: LAMBDA (Y)
+ ; (LAMBDA (Y) (FOO Y))
+ ;
+ ; caught STYLE-WARNING:
+ ; The variable Y is defined but never used.
+
+244: "optimizing away tests for &KEY args of type declared in DEFKNOWN"
+ (caught by clocc-ansi-test :EXCEPSIT-LEGACY-1050)
+ In sbcl-0.pre8.44, (OPEN "foo" :DIRECTION :INPUT :EXTERNAL-FORMAT 'FOO)
+ succeeds with no error (ignoring the bogus :EXTERNAL-FORMAT argument)
+ apparently because the test is optimized away. The problem doesn't
+ exist in sbcl-0.pre8.19. Deleting the (MEMBER :DEFAULT) declaration
+ for :EXTERNAL-FORMAT in DEFKNOWN OPEN (and LOAD) is a workaround for
+ the problem (and should be removed when the problem is fixed).
+
+245: bugs in disassembler
+ a. On X86 an immediate operand for IMUL is printed incorrectly.
+ b. On X86 operand size prefix is not recognized.
+
+246: "NTH-VALUE scaling problem"
+ NTH-VALUE's current implementation for constant integers scales in
+ compile-time as O(n^4), as indeed must the optional dispatch
+ mechanism on which it is implemented. While it is unlikely to
+ matter in real user code, it's still unpleasant to observe that
+ (NTH-VALUE 1000 (VALUES-LIST (MAKE-LIST 1001))) takes several hours
+ to compile.
+
+247: "incomplete conversion of stack parameters in #-SB-THREAD code"
+ In 0.pre8.67/x86/nothreads, executing (ROOM) causes an error to
+ be signalled:
+ The variable SB-VM:CONTROL-STACK-END is unbound.
+ (When this is fixed, the ROOM entries in tests/smoke.impure.lisp
+ should be uncommented.)
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.