program, even if you know or guess enough about the internals of
SBCL to wager that this (undefined in ANSI) operation would be safe.
-3:
+3: "type checking of structure slots"
+ a:
ANSI specifies that a type mismatch in a structure slot
initialization value should not cause a warning.
WORKAROUND:
Such code should compile without complaint and work correctly either
on SBCL or on any other completely compliant Common Lisp system.
-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.
+ b: &AUX argument in a boa-constructor without a default value means
+ "do not initilize this slot" and does not cause type error. But
+ an error may be signalled at read time and it would be good if
+ SBCL did it.
+
+ c: Reading of not initialized slot sometimes causes SEGV (for inline
+ accessors it is fixed, but out-of-line still do not perform type
+ check).
+
+ d:
+ (declaim (optimize (safety 3) (speed 1) (space 1)))
+ (defstruct foo
+ x y)
+ (defstruct (stringwise-foo (:include foo
+ (x "x" :type simple-string)
+ (y "y" :type simple-string))))
+ (defparameter *stringwise-foo*
+ (make-stringwise-foo))
+ (setf (foo-x *stringwise-foo*) 0)
+ (defun frob-stringwise-foo (sf)
+ (aref (stringwise-foo-x sf) 0))
+ (frob-stringwise-foo *stringwise-foo*)
+ SEGV.
7:
The "compiling top-level form:" output ought to be condensed.
(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,
not a binary input stream, but instead cheerfully reads from
character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
-47:
- DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
- d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
- causes a COMPILER-ERROR.
-
-51:
- miscellaneous errors reported by Peter Van Eynde July 25, 2000:
- a: (PROGN
- (DEFGENERIC FOO02 (X))
- (DEFMETHOD FOO02 ((X NUMBER)) T)
- (LET ((M (FIND-METHOD (FUNCTION FOO02)
- NIL
- (LIST (FIND-CLASS (QUOTE NUMBER))))))
- (REMOVE-METHOD (FUNCTION FOO02) M)
- (DEFGENERIC FOO03 (X))
- (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.
then requesting a BACKTRACE at the debugger prompt gives no information
about where in the user program the problem occurred.
-62:
- The compiler is supposed to do type inference well enough that
- the declaration in
- (TYPECASE X
- ((SIMPLE-ARRAY SINGLE-FLOAT)
- (LOCALLY
- (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
- ..))
- ..)
- is redundant. However, as reported by Juan Jose Garcia Ripoll for
- CMU CL, it sometimes doesn't. Adding declarations is a pretty good
- workaround for the problem for now, but can't be done by the TYPECASE
- macros themselves, since it's too hard for the macro to detect
- assignments to the variable within the clause.
- Note: The compiler *is* smart enough to do the type inference in
- many cases. This case, derived from a couple of MACROEXPAND-1
- calls on Ripoll's original test case,
- (DEFUN NEGMAT (A)
- (DECLARE (OPTIMIZE SPEED (SAFETY 0)))
- (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL
- (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
- (LET ((I 0) (G2554 LENGTH))
- (DECLARE (TYPE REAL G2554) (TYPE REAL I))
- (TAGBODY
- SB-LOOP::NEXT-LOOP
- (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
- (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
- (GO SB-LOOP::NEXT-LOOP)
- SB-LOOP::END-LOOP))))))
- demonstrates the problem; but the problem goes away if the TAGBODY
- and GO forms are removed (leaving the SETF in ordinary, non-looping
- code), or if the TAGBODY and GO forms are retained, but the
- assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)).
-
63:
Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
I am looking into this problem that showed up on the cmucl-help
(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
forever, even when it is uninterned and all other references to it
are lost.
-141:
- Pretty-printing nested backquotes doesn't work right, as
- reported by Alexey Dejneka sbcl-devel 2002-01-13:
- * '``(FOO ,@',@S)
- ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
- * (lisp-implementation-version)
- "0.pre7.129"
+141: "pretty printing and backquote"
+ a.
+ * '``(FOO ,@',@S)
+ ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
+
+ b.
+ * (write '`(, .ala.) :readably t :pretty t)
+ `(,.ALA.)
+
+ (note the space between the comma and the point)
143:
(reported by Jesse Bouwman 2001-10-24 through the unfortunately
expansion, leaving garbage consisting of infinished blocks of the
partially converted function.)
-157:
- Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
- UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
- (reported by Alexey Dejneka sbcl-devel 2002-04-12)
+ (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)
code. Since then the warning has been downgraded to STYLE-WARNING,
so it's still a bug but at least it's a little less annoying.
-178: "AVER failure compiling confused THEs in FUNCALL"
- In sbcl-0.7.4.24, compiling
- (defun bug178 (x)
- (funcall (the function (the standard-object x))))
- gives
- failed AVER:
- "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
- This variant compiles OK, though:
- (defun bug178alternative (x)
- (funcall (the nil x)))
-
- (since 0.7.8.9 it does not signal an error; see also bug 199)
-
183: "IEEE floating point issues"
Even where floating point handling is being dealt with relatively
well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), 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
c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
lists and &KEY arguments) do not signal errors when they should.
-192: "Python treats free type declarations as promises."
- b. What seemed like the same fundamental problem as bug 192a, but
- was not fixed by the same (APD "more strict type checking
- sbcl-devel 2002-08-97) patch:
- (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)):
- (declaim (optimize (speed 1) (safety 3)))
- (defun trust-assertion (i)
- (dotimes (j i)
- (declare (type (mod 4) i)) ; when commented out, behavior changes!
- (unless (< i 5)
- (print j))))
- (trust-assertion 6) ; prints nothing unless DECLARE is commented out
-
- (see bug 203)
-
-194: "no error from (THE REAL '(1 2 3)) in some cases"
- fixed parts:
- a. In sbcl-0.7.7.9,
- (multiple-value-prog1 (progn (the real '(1 2 3))))
- returns (1 2 3) instead of signalling an error. This was fixed by
- APD's "more strict type checking patch", but although the fixed
- code (in sbcl-0.7.7.19) works (signals TYPE-ERROR) interactively,
- it's difficult to write a regression test for it, because
- (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
- still returns (1 2 3).
- still-broken parts:
- b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
- returns (1 2 3). (As above, this shows up when writing regression
- tests for fixed-ness of part a.)
- c. Also in sbcl-0.7.7.9, (IGNORE-ERRORS (THE REAL '(1 2 3))) => (1 2 3).
- d. At the REPL,
- (null (ignore-errors
- (let ((arg1 1)
- (arg2 (identity (the real #(1 2 3)))))
- (if (< arg1 arg2) arg1 arg2))))
- => T
- but putting the same expression inside (DEFUN FOO () ...),
- (FOO) => NIL.
- notes:
- * Actually this entry is probably multiple bugs, as
- Alexey Dejneka commented on sbcl-devel 2002-09-03:)
- I don't think that placing these two bugs in one entry is
- a good idea: they have different explanations. The second
- (min 1 nil) is caused by flushing of unused code--IDENTITY
- can do nothing with it. So it is really bug 122. The first
- (min nil) is due to M-V-PROG1: substituting a continuation
- for the result, it forgets about type assertion. The purpose
- of IDENTITY is to save the restricted continuation from
- inaccurate transformations.
- * Alexey Dejneka pointed out that
- (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3))))
- works as it should. Also
- (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3))))
- works as it should. Perhaps this is another case of VALUES type
- intersections behaving in non-useful ways?
-
-199: "hairy FUNCTION types confuse the compiler"
- (reported by APD sbcl-devel 2002-09-15)
- (DEFUN MUR (F)
- (EQ NIL (FUNCALL F)))
-
- (DEFUN FOO (F X)
- (DECLARE (TYPE (AND FUNCTION (SATISFIES MUR)) F))
- (FUNCALL F X))
-
- fails to compile, printing
- failed AVER:
- "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
-
- APD further reports that this bug is not present in CMUCL.
-
- (this case was fixed in 0.7.8.9; see also bug 178)
201: "Incautious type inference from compound CONS types"
(reported by APD sbcl-devel 2002-09-17)
(FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
-203:
- Compiler does not check THEs on unused values, e.g. in
-
- (progn (the real (list 1)) t)
-
- This situation may appear during optimizing away degenerate cases of
- certain functions: see bug 192b.
-
205: "environment issues in cross compiler"
(These bugs have no impact on user code, but should be fixed or
documented.)
(the integer (helper))
nil)
- Type check for INTEGER is inserted, the result of which serves as
- the first argument of M-V-C, is inserted after evaluation of NIL. So
- arguments of M-V-C are pushed in the wrong order. As a temporary
- workaround type checking was disabled for M-V-Cs in 0.7.9.13. A
- better solution would be to put a check between evaluation of
- arguments, but it could be tricky to check result types of PROG1, IF
- etc.
-
-222: "environment problems in PCL"
- Evaluating
-
- (symbol-macrolet ((x 1))
- (defmethod foo (z)
- (macrolet ((ml (form) `(progn ,form ,x)))
- (ml (print x)))))
-
- causes
-
- debugger invoked on condition of type UNBOUND-VARIABLE:
- The variable X is unbound.
-
-223: "(SETF FDEFINITION) and #' semantics broken for wrappers"
- Although this
- (defun foo (x)
- (print x))
- (defun traced (fn)
- (lambda (&rest rest)
- (format t "~&about to call ~S on ~S~%" fn rest)
- (apply fn rest)
- (format t "~&returned from ~S~%" fn)))
- (setf (fdefinition 'foo)
- (traced #'foo))
- (foo 11)
- does what one would expect, this
- (defun bar (x)
- (print x))
- (let ((bar0 #'bar))
- (setf (fdefinition 'bar)
- (lambda (&rest rest)
- (format t "~&about to enter BAR ~S~%" rest)
- (apply bar0 rest)
- (format t "~&back from BAR~%"))))
- (bar 12)
- recurses endlessly in sbcl-0.7.9.32. (Or it works if #' and
- FDEFINITION are replaced by SYMBOL-FUNCTION.)
-
-224:
- SBCL 0.7.8 fails to compile
- (localy (declare (optimize (safety 3)))
- (ignore-errors (progn (values-list (car (list '(1 . 2)))) t)))
- (the LOCALY there is not a typo; any unknown function (e.g. FROB)
- will do).
-
-228: "function-lambda-expression problems"
- in sbcl-0.7.9.6x, from the REPL:
- * (progn (declaim (inline foo)) (defun foo (x) x))
- FOO
- * (function-lambda-expression #'foo)
- (SB-C:LAMBDA-WITH-LEXENV NIL NIL NIL (X) (BLOCK FOO X)), NIL, FOO
- but this first return value is not suitable for input to FUNCTION or
- COMPILE, as required by ANSI.
+ Type check for INTEGER, the result of which serves as the first
+ argument of M-V-C, is inserted after evaluation of NIL. So arguments
+ of M-V-C are pushed in the wrong order. As a temporary workaround
+ type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
+ would be to put the check between evaluation of arguments, but it
+ could be tricky to check result types of PROG1, IF etc.
229:
(subtypep 'function '(function)) => nil, t.
-230:
- (fixed in 0.7.10.5)
+233: bugs in constraint propagation
+ a.
+ (defun foo (x)
+ (declare (optimize (speed 2) (safety 3)))
+ (let ((y 0d0))
+ (values
+ (the double-float x)
+ (setq y (+ x 1d0))
+ (setq x 3d0)
+ (quux y (+ y 2d0) (* y 3d0)))))
+ (foo 4) => segmentation violation
+
+ (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS)
+ (see also bug 236)
+
+ b.
+ (declaim (optimize (speed 2) (safety 3)))
+ (defun foo (x y)
+ (if (typep (prog1 x (setq x y)) 'double-float)
+ (+ x 1d0)
+ (+ x 2)))
+ (foo 1d0 5) => segmentation violation
+
+235: "type system and inline expansion"
+ a.
+ (declaim (ftype (function (cons) number) acc))
+ (declaim (inline acc))
+ (defun acc (c)
+ (the number (car c)))
+
+ (defun foo (x y)
+ (values (locally (declare (optimize (safety 0)))
+ (acc x))
+ (locally (declare (optimize (safety 3)))
+ (acc y))))
+
+ (foo '(nil) '(t)) => NIL, T.
+
+ b. (reported by brown on #lisp 2003-01-21)
+
+ (defun find-it (x)
+ (declare (optimize (speed 3) (safety 0)))
+ (declare (notinline mapcar))
+ (let ((z (mapcar #'car x)))
+ (find 'foobar z)))
+
+ Without (DECLARE (NOTINLINE MAPCAR)), Python cannot derive that Z is
+ LIST.
+
+237: "Environment arguments to type functions"
+ a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
+ UPGRADED-COMPLEX-PART-TYPE now have an optional environment
+ argument, but they ignore it completely. This is almost
+ certainly not correct.
+ b. Also, the compiler's optimizers for TYPEP have not been informed
+ about the new argument; consequently, they will not transform
+ calls of the form (TYPEP 1 'INTEGER NIL), even though this is
+ just as optimizeable as (TYPEP 1 'INTEGER).
+
+238: "REPL compiler overenthusiasm for CLOS code"
+ From the REPL,
+ * (defclass foo () ())
+ * (defmethod bar ((x foo) (foo foo)) (call-next-method))
+ causes approximately 100 lines of code deletion notes. Some
+ discussion on this issue happened under the title 'Three "interesting"
+ bugs in PCL', resulting in a fix for this oververbosity from the
+ compiler proper; however, the problem persists in the interactor
+ because the notion of original source is not preserved: for the
+ compiler, the original source of the above expression is (DEFMETHOD
+ BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the
+ compiler gets its hands on the code needing compilation from the REPL,
+ it has been macroexpanded several times.
+
+ 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)))
+ (profile foo-bar)
+ (unintern 'foo-bar)
+ (defclass foo () ((bar :accessor foo-bar)))
+ gives the error message
+ "#:FOO-BAR already names an ordinary function or a macro."
+ 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.
+
+248: "reporting errors in type specifier syntax"
+ (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type
+ specifier".
+
+250:
+ (make-array nil :initial-element 11) causes a warning.
+
+251:
+ (defun foo (&key (a :x))
+ (declare (fixnum a))
+ a)
+
+ does not cause a warning. (BTW: old SBCL issued a warning, but for a
+ function, which was never called!)
DEFUNCT CATEGORIES OF BUGS
IR1-#: