then executing
(FOO 1.5)
will cause the INTEGERP case to be selected, giving bogus output a la
- exactly 1.33..
+ exactly 2.5
This violates the "declarations are assertions" principle.
According to the ANSI spec, in the section "System Class FUNCTION",
this is a case of "lying to the compiler", but the lying is done
47:
DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
- a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and
- doesn't.
- b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should
- signal a PROGRAM-ERROR, and doesn't.
- c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))),
- and other DEFCLASS forms with duplicate specifications in their
- slots, should signal a PROGRAM-ERROR, and doesn't.
d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
causes a COMPILER-ERROR.
(DEFGENERIC FOO03 (X))
(ADD-METHOD (FUNCTION FOO03) M)))
should give an error, but SBCL allows it.
- b: READ should probably return READER-ERROR, not the bare
- arithmetic error, when input a la "1/0" or "1e1000" causes
- an arithmetic error.
52:
It has been reported (e.g. by Peter Van Eynde) that there are
the new output block should start indented 2 or more characters
rightward of the correct location.
-65:
- (probably related to bug #70; maybe related to bug #109)
- As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
- compiling this file
-(in-package "CL-USER")
-(defun equal-terms (termx termy)
- (labels
- ((alpha-equal-bound-term-lists (listx listy)
- (or (and (null listx) (null listy))
- (and listx listy
- (let ((bindings-x (bindings-of-bound-term (car listx)))
- (bindings-y (bindings-of-bound-term (car listy))))
- (if (and (null bindings-x) (null bindings-y))
- (alpha-equal-terms (term-of-bound-term (car listx))
- (term-of-bound-term (car listy)))
- (and (= (length bindings-x) (length bindings-y))
- (prog2
- (enter-binding-pairs (bindings-of-bound-term (car listx))
- (bindings-of-bound-term (car listy)))
- (alpha-equal-terms (term-of-bound-term (car listx))
- (term-of-bound-term (car listy)))
- (exit-binding-pairs (bindings-of-bound-term (car listx))
- (bindings-of-bound-term (car listy)))))))
- (alpha-equal-bound-term-lists (cdr listx) (cdr listy)))))
-
- (alpha-equal-terms (termx termy)
- (if (and (variable-p termx)
- (variable-p termy))
- (equal-bindings (id-of-variable-term termx)
- (id-of-variable-term termy))
- (and (equal-operators-p (operator-of-term termx) (operator-of-term termy))
- (alpha-equal-bound-term-lists (bound-terms-of-term termx)
- (bound-terms-of-term termy))))))
-
- (or (eq termx termy)
- (and termx termy
- (with-variable-invocation (alpha-equal-terms termx termy))))))
- causes an assertion failure
- The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER)
- (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed.
-
- Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test
- case with the same problem:
-(defun parse-fssp-alignment ()
- ;; Given an FSSP alignment file named by the argument . . .
- (labels ((get-fssp-char ()
- (get-fssp-char))
- (read-fssp-char ()
- (get-fssp-char)))
- ;; Stub body, enough to tickle the bug.
- (list (read-fssp-char)
- (read-fssp-char))))
-
66:
ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
crashes SBCL. In general tracing anything which is used in the
implementation of TRACE is likely to have the same problem.
-70:
- (probably related to bug #65; maybe related to bug #109)
- The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
- forms. E.g.
- (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
- (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL))
- (LET ((ITEM (FIRST SEQ)))
- (COND ((NULL SEQ)
- (VALUES NIL NIL))
- ((FUNCALL TEST OBJ ITEM)
- (VALUES VAL SEQ))
- (T
- (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM))))))))
- (FIND-ITEM ITEM SEQUENCE TEST)))
- from David Young's bug report on cmucl-help@cons.org 30 Nov 2000
- causes sbcl-0.6.9 to fail with
- error in function SB-KERNEL:ASSERT-ERROR:
- The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER)
- (SB-C::LAMBDA-TAIL-SET
- (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
-
72:
(DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
time trying to GC afterwards. Surely there's some more economical
way to implement (ROOM T).
-109:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- ;;; This file fails to compile.
- ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file.
- (in-package :cl-user)
- (defun tst2 ()
- (labels
- ((eff (&key trouble)
- (eff)
- ;; nil
- ;; Uncomment and it works
- ))
- (eff)))
- In SBCL 0.6.12.42, the problem is
- internal error, failed AVER:
- "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER)
- (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))"
-
-110:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- ;;; The compiler is flushing the argument type test, and the default
- ;;; case in the cond, so that calling with say a fixnum 0 causes a
- ;;; SIGBUS.
- (declaim (optimize (safety 2) (speed 3)))
- (defun tst (x)
- (declare (type (or string stream) x))
- (cond ((typep x 'string) 'string)
- ((typep x 'stream) 'stream)
- (t
- 'none)))
- The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM
- (not the SIGBUS reported in the comment) but that's broken too;
- type declarations are supposed to be treated as assertions unless
- SAFETY 0, so we should be getting a TYPE-ERROR.
-
-113:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- (in-package :cl-user)
- ;;; From: David Gadbois <gadbois@cyc.com>
- ;;;
- ;;; Logical pathnames aren't externalizable.
- ;;; Test case:
- (let ((tempfile "/tmp/test.lisp"))
- (setf (logical-pathname-translations "XXX")
- '(("XXX:**;*.*" "/tmp/**/*.*")))
- (with-open-file (out tempfile :direction :output)
- (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out))
- (compile-file tempfile))
- The error message in sbcl-0.6.12.42 is
- ; caught ERROR:
- ; (while making load form for #<SB-IMPL::LOGICAL-HOST "XXX">)
- ; A logical host can't be dumped as a constant: #<SB-IMPL::LOGICAL-HOST "XXX">
-
115:
reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
collection:
Raymond Toy comments that this is tricky on the X86 since its FPU
uses 80-bit precision internally.
-120a:
- The compiler incorrectly figures the return type of
- (DEFUN FOO (FRAME UP-FRAME)
- (IF (OR (NOT FRAME)
- T)
- FRAME
- "BAR"))
- as NIL.
-
- This problem exists in CMU CL 18c too. When I reported it on
- cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with
- a partial explanation, but no fix has been found yet.
-
120b:
Even in sbcl-0.pre7.x, which is supposed to be free of the old
non-ANSI behavior of treating the function return type inferred
(IF (NOT (IGNORE-ERRORS ..))). E.g.
(defun foo1i ()
(if (not (ignore-errors
- (make-pathname :host "foo" :directory "!bla" :name "bar")))
+ (make-pathname :host "foo"
+ :directory "!bla"
+ :name "bar")))
(print "ok")
(error "notunlessnot")))
The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
#+NIL) and I'd like to go back to see whether this really is
a compiler bug before I delete this BUGS entry.
-123:
- The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly
- (IN-PACKAGE :SB-KERNEL)
- (TYPE= (SPECIFIER-TYPE '(VECTOR T))
- (SPECIFIER-TYPE '(VECTOR UNDEFTYPE)))
- Then because of this, the compiler bogusly optimizes
- (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1))
- to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to
- NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained
- about type mismatches (probably harmlessly, another instance of bug 117);
- and then cold init died with a segmentation fault.
-
124:
As of version 0.pre7.14, SBCL's implementation of MACROLET makes
the entire lexical environment at the point of MACROLET available
(bar x)))
shouldn't compile without error (because of the extra DEFMACRO symbol).
-131:
- As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably
- the CL:COMPILE function (which is based on the same %COMPILE
- mechanism) get confused by
-(defun sxhash (x)
- (labels ((sxhash-number (x)
- (etypecase x
- (fixnum (sxhash x)) ; through DEFTRANSFORM
- (integer (sb!bignum:sxhash-bignum x))
- (single-float (sxhash x)) ; through DEFTRANSFORM
- (double-float (sxhash x)) ; through DEFTRANSFORM
- #!+long-float (long-float (error "stub: no LONG-FLOAT"))
- (ratio (let ((result 127810327))
- (declare (type fixnum result))
- (mixf result (sxhash-number (numerator x)))
- (mixf result (sxhash-number (denominator x)))
- result))
- (complex (let ((result 535698211))
- (declare (type fixnum result))
- (mixf result (sxhash-number (realpart x)))
- (mixf result (sxhash-number (imagpart x)))
- result))))
- (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
- (declare (type index depthoid))
- (typecase x
- (list
- (if (plusp depthoid)
- (mix (sxhash-recurse (car x) (1- depthoid))
- (sxhash-recurse (cdr x) (1- depthoid)))
- 261835505))
- (instance
- (if (typep x 'structure-object)
- (logxor 422371266
- (sxhash ; through DEFTRANSFORM
- (class-name (layout-class (%instance-layout x)))))
- 309518995))
- (symbol (sxhash x)) ; through DEFTRANSFORM
- (number (sxhash-number x))
- (array
- (typecase x
- (simple-string (sxhash x)) ; through DEFTRANSFORM
- (string (%sxhash-substring x))
- (bit-vector (let ((result 410823708))
- (declare (type fixnum result))
- (dotimes (i (min depthoid (length x)))
- (mixf result (aref x i)))
- result))
- (t (logxor 191020317 (sxhash (array-rank x))))))
- (character
- (logxor 72185131
- (sxhash (char-code x)))) ; through DEFTRANSFORM
- (t 42))))
- (sxhash-recurse x)))
- complaining "function called with two arguments, but wants exactly
- one" about SXHASH-RECURSE. (This might not be strictly a new bug,
- since IIRC post-fork CMU CL has also had problems with &OPTIONAL
- arguments in FLET/LABELS: it might be an old Python bug which is
- only exercised by the new arrangement of the SBCL compiler.)
-
135:
Ideally, uninterning a symbol would allow it, and its associated
FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper
class upon redefinition. Unfortunately, doing so causes bug #176 to
- appear. Pending further investication, one or other of these bugs
+ appear. Pending further investigation, one or other of these bugs
might be present at any given time.
141:
* (lisp-implementation-version)
"0.pre7.129"
-142:
- (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16)
- %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte
- of the naturalized string. We could probably port the patches
- from the cmucl-imp mailing list.
-
143:
(reported by Jesse Bouwman 2001-10-24 through the unfortunately
prominent SourceForge web/db bug tracking system, which is
issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
-153:
- (essentially the same problem as a CMU CL bug reported by Martin
- Cracauer on cmucl-imp 2002-02-19)
- There is a hole in structure slot type checking. Compiling and LOADing
- (declaim (optimize safety))
- (defstruct foo
- (bla 0 :type fixnum))
- (defun f ()
- (let ((foo (make-foo)))
- (setf (foo-bla foo) '(1 . 1))
- (format t "Is ~a of type ~a a cons? => ~a~%"
- (foo-bla foo)
- (type-of (foo-bla foo))
- (consp (foo-bla foo)))))
- (f)
- should signal an error, but in sbcl-0.7.1.21 instead gives the output
- Is (1 . 1) of type CONS a cons? => NIL
- without signalling an error.
-
157:
Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
isn't too surprising since there are many differences in stack
implementation and GC conservatism between the X86 and other ports.)
-165:
- Array types with element-types of some unknown type are falsely being
- assumed to be of type (ARRAY T) by the compiler in some cases. The
- following code demonstrates the problem:
-
- (defun foo (x)
- (declare (type (vector bar) x))
- (aref x 1))
- (deftype bar () 'single-float)
- (foo (make-array 3 :element-type 'bar))
- -> TYPE-ERROR "The value #(0.0 0.0 0.0) is not of type (VECTOR BAR)."
- (typep (make-array 3 :element-type 'bar) '(vector bar))
- -> T
-
- The easy solution is to make the functions which depend on knowing
- the upgraded-array-element-type (in compiler/array-tran and
- compiler/generic/vm-tran as of sbcl-0.7.3.x) be slightly smarter about
- unknown types; an alternative is to have the
- specialized-element-type slot in the ARRAY-TYPE structure be
- *WILD-TYPE* for UNKNOWN-TYPE element types.
-
166:
Compiling
(in-package :cl-user)
macro is unhappy with the illegal syntax in the method body, and
is giving an unclear error message.
-168:
- (reported by Dan Barlow on sbcl-devel 2002-05-10)
- In sbcl-0.7.3.12, doing
- (defstruct foo bar baz)
- (compile nil (lambda (x) (or x (foo-baz x))))
- gives an error
- debugger invoked on condition of type SB-INT:BUG:
- full call to SB-KERNEL:%INSTANCE-REF
- This is probably a bug in SBCL itself. [...]
- Since this is a reasonable user error, it shouldn't be reported as
- an SBCL bug.
-
-171:
- (reported by Pierre Mai while investigating bug 47):
- (DEFCLASS FOO () ((A :SILLY T)))
- signals a SIMPLE-ERROR, not a PROGRAM-ERROR.
-
172:
sbcl's treatment of at least macro lambda lists is too permissive;
e.g., in sbcl-0.7.3.7:
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.
-174:
- The error message from attempting to use a #\Return format
- directive:
- (format nil "~^M") ; replace "^M" with a literal #\Return
- debugger invoked on condition of type SB-FORMAT::FORMAT-ERROR:
- error in format: unknown format directive
- ~
- ^
- is not terribly helpful; this is more noticeable than parallel cases
- with e.g. #\Backspace because of the differing newline conventions
- on various operating systems. (reported by Harald Hanche-Olsen on
- cmucl-help 2002-05-31)
-
176:
reported by Alexey Dejneka 08 Jun 2002 in sbcl-devel:
Playing with McCLIM, I've received an error "Unbound variable WRAPPER
(defun bug178alternative (x)
(funcall (the nil x)))
-181: "bad type specifier drops compiler into debugger"
- Compiling
- (in-package :cl-user)
- (defun bar (x)
- (declare (type 0 x))
- (cons x x))
- signals
- bad thing to be a type specifier: 0
- which seems fine, but also enters the debugger (instead of having
- the compiler handle the error, convert it into a COMPILER-ERROR, and
- continue compiling) which seems wrong.
-
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
only sporadically reproducible.
191: "Miscellaneous PCL deficiencies"
- (reported by Alexey Dejenka sbcl-devel 2002-08-04)
+ (reported by Alexey Dejneka sbcl-devel 2002-08-04)
a. DEFCLASS does not inform the compiler about generated
functions. Compiling a file with
(DEFCLASS A-CLASS ()
results in a STYLE-WARNING:
undefined-function
SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER|
+
+ APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre
+ Mai points out that the declamation of functions is in fact
+ incorrect in some cases (most notably for structure
+ classes). This means that at present erroneous attempts to use
+ WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
+ won't get the corresponding STYLE-WARNING.
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
+
+193: "unhelpful CLOS error reporting when the primary method is missing"
+ In sbcl-0.7.7, when
+ (defmethod foo :before ((x t)) (print x))
+ is the only method defined on FOO, the error reporting when e.g.
+ (foo 12)
+ is relatively unhelpful:
+ There is no primary method for the generic function
+ #<STANDARD-GENERIC-FUNCTION FOO (1)>.
+ with the offending argument nowhere visible in the backtrace. This
+ continues even if there *are* primary methods, just not for the
+ specified arg type, e.g.
+ (defmethod foo ((x character)) (print x))
+ (defmethod foo ((x string)) (print x))
+ (defmethod foo ((x pathname)) ...)
+ In that case it could be very helpful to know what argument value is
+ falling through the cracks of the defined primary methods, but the
+ error message stays the same (even BACKTRACE doesn't tell you what the
+ bad argument value is).
+
+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.
+
+201: "Incautious type inference from compound CONS types"
+ (reported by APD sbcl-devel 2002-09-17)
+ (DEFUN FOO (X)
+ (LET ((Y (CAR (THE (CONS INTEGER *) X))))
+ (SETF (CAR X) NIL)
+ (FORMAT NIL "~S IS ~S, Y = ~S"
+ (CAR X)
+ (TYPECASE (CAR X)
+ (INTEGER 'INTEGER)
+ (T '(NOT INTEGER)))
+ Y)))
+
+ (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
+
+202:
+ In 0.6.12.43 compilation of a function definition, contradicting its
+ FTYPE proclamation, causes an error, e.g. COMPILE-FILE on
+
+ (declaim (ftype (function () null) foo))
+ (defun foo () t)
+
+ fails with
+
+ debugger invoked on condition of type UNBOUND-VARIABLE:
+ The variable SB-C::*ERROR-FUNCTION* is unbound.
+
+ in
+
+ (SB-C::NOTE-LOSSAGE
+ "~@<The previously declared FTYPE~2I ~_~S~I ~_~
+ conflicts with the definition type ~2I~_~S~:>"
+ (FUNCTION NIL NULL)
+ (FUNCTION NIL #))
+
+ (In 0.7.0 the variable was renamed to SB-C::*LOSSAGE-FUN*.)
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.