MERGE also have the same problem.
c: (COERCE 'AND 'FUNCTION) returns something related to
(MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
- g: (LOAD "*.lsp") should signal FILE-ERROR.
h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
should signal TYPE-ERROR.
i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
crashes SBCL. In general tracing anything which is used in the
implementation of TRACE is likely to have the same problem.
-68:
- As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23,
- SXHASH returns the same value for all non-STRUCTURE-OBJECT instances,
- notably including all PCL instances. There's a limit to how much
- SXHASH can do to return unique values for instances, but at least
- it should probably look at the class name, the way that it does
- for STRUCTURE-OBJECTs.
-
70:
(probably related to bug #65; maybe related to bug #109)
The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
(SB-C::LAMBDA-TAIL-SET
(SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
-71:
- (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after
- (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with
- the previous SPEED policy. This bug will probably get fixed in
- 0.6.9.x in a general cleanup of optimization policy.
-
72:
(DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
Evidently Python thinks of the lambda as a code transformation so
much that it forgets that it's also an object.
-126:
- (fixed in 0.pre7.41)
-
127:
The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
specifies a precedence rule for name collisions between slot accessors of
(let ((x (1+ x)))
(call-next-method)))
Now (FOO 3) should return 3, but instead it returns 4.
-
-137:
- (SB-DEBUG:BACKTRACE) output should start with something
- including the name BACKTRACE, not (as in 0.pre7.88)
- just "0: (\"hairy arg processor\" ...)". Until about
- sbcl-0.pre7.109, the names in BACKTRACE were all screwed
- up compared to the nice useful names in sbcl-0.6.13.
- Around sbcl-0.pre7.109, they were mostly fixed by using
- NAMED-LAMBDA to implement DEFUN. However, there are still
- some screwups left, e.g. as of sbcl-0.pre7.109, there are
- still some functions named "hairy arg processor" and
- "SB-INT:&MORE processor".
140:
(reported by Alexey Dejneka sbcl-devel 2002-01-03)
T
T
- This is probably due to underzealous clearing of the type caches; a
- brute-force solution in that case would be to make a defclass expand
- into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES,
- but there may be a better solution.
+ 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
+ might be present at any given time.
141:
Pretty-printing nested backquotes doesn't work right, as
but it has happened in more complicated cases (which I haven't
figured out how to reproduce).
-155:
- (fixed in sbcl-0.7.2.9)
-
156:
FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9:
* (function-lambda-expression #'(lambda (x) x))
UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
(reported by Alexey Dejneka sbcl-devel 2002-04-12)
-158:
- Compiling the following code causes SBCL 0.7.2 to bug. This only
- happens with optimization enabled, and only when the loop variable is
- being incremented by more than 1.
- (defun foo (array)
- (declare (optimize (safety 0) (space 0) (debug 0) (speed 3)))
- (loop for i from 0 to 10 by 2
- do (foo (svref array i))) (svref array (1+ i)))
- (reported by Eric Marsden sbcl-devel 2002-04-15)
-
162:
(reported by Robert E. Brown 2002-04-16)
When a function is called with too few arguments, causing the
isn't too surprising since there are many differences in stack
implementation and GC conservatism between the X86 and other ports.)
-164:
- The type system still can't quite deal with all useful identities;
- for instance, as of sbcl-0.7.2.18, the type specifier '(and (real -1
- 7) (real 4 8)) is a HAIRY-TYPE rather than that which would be hoped
- for, viz: '(real 4 7).
-
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
Since this is a reasonable user error, it shouldn't be reported as
an SBCL bug.
-169:
- (reported by Alexey Dejneka on sbcl-devel 2002-05-12)
- * (defun test (n)
- (let ((*x* n))
- (declare (special *x*))
- (getx)))
- ; in: LAMBDA NIL
- ; (LET ((*X* N))
- ; (DECLARE (SPECIAL *X*))
- ; (GETX))
- ;
- ; caught STYLE-WARNING:
- ; using the lexical binding of the symbol *X*, not the
- ; dynamic binding, even though the symbol name follows the usual naming
- ; convention (names like *FOO*) for special variables
- ; compilation unit finished
- ; caught 1 STYLE-WARNING condition
- But the code works as it should. Checked in 0.6.12.43 and later.
+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:
+ (defmacro foo (&rest rest bar) `(,bar ,rest))
+ (macroexpand '(foo quux zot)) -> (QUUX (QUUX ZOT))
+ whereas section 3.4.4 of the CLHS doesn't allow required parameters
+ to come after the rest argument.
+
+173:
+ The compiler sometimes tries to constant-fold expressions before
+ it checks to see whether they can be reached. This can lead to
+ bogus warnings about errors in the constant folding, e.g. in code
+ like
+ (WHEN X
+ (WRITE-STRING (> X 0) "+" "0"))
+ compiled in a context where the compiler can prove that X is NIL,
+ and the compiler complains that (> X 0) causes a type error because
+ NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this
+ caused a full WARNING, which made the bug really annoying because then
+ COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal
+ 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
+ in SB-PCL::CHECK-WRAPPER-VALIDITY".
+ (defun check-wrapper-validity (instance)
+ (let* ((owrapper (wrapper-of instance)))
+ (if (not (invalid-wrapper-p owrapper))
+ owrapper
+ (let* ((state (wrapper-state wrapper)) ; !!!
+ ...
+ I've tried to replace it with OWRAPPER, but now OBSOLETE-INSTANCE-TRAP
+ breaks with "NIL is not of type SB-KERNEL:LAYOUT".
+ SBCL 0.7.4.13.
+ partial fix: The undefined variable WRAPPER resulted from an error
+ in recent refactoring, as can be seen by comparing to the code in e.g.
+ sbcl-0.7.2. Replacing WRAPPER with OWRAPPER (done by WHN in sbcl-0.7.4.22)
+ should bring the code back to its behavior as of sbcl-0.7.2, but
+ that still leaves the OBSOLETE-INSTANCE-TRAP bug. An example of
+ input which triggers that bug is
+ (dotimes (i 20)
+ (let ((lastname (intern (format nil "C~D" (1- i))))
+ (name (intern (format nil "C~D" i))))
+ (eval `(defclass ,name
+ (,@(if (= i 0) nil (list lastname)))
+ ()))
+ (eval `(defmethod initialize-instance :after ((x ,name) &rest any)
+ (declare (ignore any))))))
+ (defclass b () ())
+ (defclass c0 (b) ())
+ (make-instance 'c19)
+
+ See also bug #140.
+
+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)))
+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.
+
+182: "SPARC/Linux floating point"
+ Evaluating (/ 1.0 0.0) at the prompt causes a Bus error and complete
+ death of the environment. Other floating point operations sometimes
+ return infinities when they should raise traps (e.g. the test case
+ for bug #146, (expt 2.0 12777)).
+
+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
+ accrued-exceptions and current-exceptions part of the fp control
+ word don't seem to bear much relation to reality. E.g. on
+ SPARC/SunOS:
+ * (/ 1.0 0.0)
+
+ debugger invoked on condition of type DIVISION-BY-ZERO:
+ arithmetic error DIVISION-BY-ZERO signalled
+ 0] (sb-vm::get-floating-point-modes)
+
+ (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
+ :ROUNDING-MODE :NEAREST
+ :CURRENT-EXCEPTIONS NIL
+ :ACCRUED-EXCEPTIONS (:INEXACT)
+ :FAST-MODE NIL)
+ 0] abort
+ * (sb-vm::get-floating-point-modes)
+ (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
+ :ROUNDING-MODE :NEAREST
+ :CURRENT-EXCEPTIONS (:INEXACT)
+ :ACCRUED-EXCEPTIONS (:INEXACT)
+ :FAST-MODE NIL)
DEFUNCT CATEGORIES OF BUGS
IR1-#: