(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))
45:
a slew of floating-point-related errors reported by Peter Van Eynde
on July 25, 2000:
- a: (fixed in sbcl-0.6.11.25)
b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT 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,
and LEAST-NEGATIVE-LONG-FLOAT.
- c: Many expressions generate floating infinity:
+ c: Many expressions generate floating infinity on x86/Linux:
(/ 1 0.0)
(/ 1 0.0d0)
(EXPT 10.0 1000)
(EXPT 10.0d0 1000)
- PVE's regression tests want them to raise errors. SBCL
- generates the infinities instead, which may or may not be
- conforming behavior.
+ PVE's regression tests want them to raise errors. sbcl-0.7.0.5
+ on x86/Linux generates the infinities instead. That might or
+ might not be conforming behavior, but it's also inconsistent,
+ which is almost certainly wrong. (Inconsistency: (/ 1 0.0)
+ should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0)
+ generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0)
+ signals an error.
d: (in section12.erg) various forms a la
(FLOAT 1 DOUBLE-FLOAT-EPSILON)
don't give the right behavior.
d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
blows up at the level of SPECIFIER-TYPE with
"Lower bound (0) is greater than upper bound (0)." Probably
- SPECIFIER-TYPE should return NIL instead.
- e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with
- "Component type for Complex is not numeric: (EQL 0)."
- This might be easy to fix; the type system already knows
- that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
+ SPECIFIER-TYPE should return the NIL type instead.
g: The type system isn't all that smart about relationships
between hairy types, as shown in the type.erg test results,
e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
The implementation of #'+ returns its single argument without
type checking, e.g. (+ "illegal") => "illegal".
-56:
- Attempting to use COMPILE on something defined by DEFMACRO fails:
- (DEFMACRO FOO (X) (CONS X X))
- (COMPILE 'FOO)
-Error in function C::GET-LAMBDA-TO-COMPILE:
- #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
-
58:
(SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
Note: I looked into fixing this in 0.6.11.15, but gave up. The
(assert (not (eq type1 *wild-type*)))
in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
in a type context should probably be translated to T, and so it's
- probably to ask whether it's equal to the T type and then (using the
- EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
+ probably wrong to ask whether it's equal to the T type and then (using
+ the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
(I haven't tried to investigate this bug enough to guess whether
there might be any user-level symptoms.)
clear what's the best fix. (See the "bug in type handling" discussion
on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
-93:
- In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
- src/cold/shared.lisp doesn't correctly translate the
- interpreted function
- (defun in-host-compilation-mode (fn)
- (let ((*features* (cons :sb-xc-host *features*))
- ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in
- ;; base-target-features.lisp-expr:
- (*shebang-features* (set-difference *shebang-features*
- '(:sb-propagate-float-type
- :sb-propagate-fun-type))))
- (with-additional-nickname ("SB-XC" "SB!XC")
- (funcall fn))))
- No error is reported by the compiler, but when the function is executed,
- it causes an error
- TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
- (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
- :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
-
94a:
Inconsistencies between derived and declared VALUES return types for
DEFUN aren't checked very well. E.g. the logic which successfully
/usr/stuff/sbcl/src/code/host-alieneval.lisp
Created: Monday, March 12, 2001 07:47:43 AM CST
-106:
- (reported by Eric Marsden on cmucl-imp 2001-06-15)
- (and APD pointed out on sbcl-devel 2001-12-29 that it's the same
- as bug 50e)
-
108:
(TIME (ROOM T)) reports more than 200 Mbytes consed even for
a clean, just-started SBCL system. And it seems to be right:
type declarations are supposed to be treated as assertions unless
SAFETY 0, so we should be getting a TYPE-ERROR.
-111:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- (in-package :cl-user)
- ;;; Produces an assertion failures when compiled.
- (defun foo (z)
- (declare (type (or (function (t) t) null) z))
- (let ((z (or z #'identity)))
- (declare (type (function (t) t) z))
- (funcall z 1)))
- The error in sbcl-0.6.12.42 is
- internal error, failed AVER:
- "(COMMON-LISP:NOT (COMMON-LISP:EQ SB!C::CHECK COMMON-LISP:T))"
-
-112:
- reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs
- collection; apparently originally reported by Bruno Haible
- (in-package :cl-user)
- ;;; From: Bruno Haible
- ;;; Subject: scope of SPECIAL declarations
- ;;; It seems CMUCL has a bug relating to the scope of SPECIAL
- ;;; declarations. I observe this with "CMU Common Lisp 18a x86-linux
- ;;; 1.4.0 cvs".
- (let ((x 0))
- (declare (special x))
- (let ((x 1))
- (let ((y x))
- (declare (special x)) y)))
- ;;; Gives: 0 (this should return 1 according to CLHS)
- (let ((x 0))
- (declare (special x))
- (let ((x 1))
- (let ((y x) (x 5))
- (declare (special x)) y)))
- ;;; Gives: 1 (correct).
- The reported results match what we get from the interpreter
- in sbcl-0.6.12.42.
-
113:
reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
collection:
(bar x)))
shouldn't compile without error (because of the extra DEFMACRO symbol).
-130:
- reported by Alexey Dejneka on sbcl-devel 2001-11-03
- (defun x (x)
- "Return X if X is a non-negative integer."
- (let ((step (lambda (%funcall)
- (lambda (n)
- (cond ((= n 0) 0)
- (t (1+ (funcall %funcall (1- n)))))))))
- (funcall
- ((lambda (a)
- (funcall step (lambda (n)
- (funcall (funcall a a) n))))
- (lambda (a)
- (funcall step (lambda (n)
- (funcall (funcall a a) n)))))
- x)))
- This function returns its argument. But after removing percents it
- does not work: "Result of (1- n) is not a function".
-
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
internal compiler error. (This error occurs in sbcl-0.6.13 and in
0.pre7.86.flaky7.14.)
-133:
- Trying to compile something like
- (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void
- (code-obj sb!c-call:unsigned-long)
- (pc-offset sb!c-call:int)
- (old-inst sb!c-call:unsigned-long))
- in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error
- cannot use values types here
- probably because the SB-C-CALL:VOID type gets translated to (VALUES).
- It should be valid to use VOID for a function return type, so perhaps
- instead of calling SPECIFIER-TYPE (which excludes all VALUES types
- automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES
- types manually, allowing the special case (VALUES) but still excluding
- all more-complex VALUES types.
-
135:
Ideally, uninterning a symbol would allow it, and its associated
FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
* (lisp-implementation-version)
"0.pre7.129"
-
-KNOWN BUGS RELATED TO THE IR1 INTERPRETER
-
-(Now that the IR1 interpreter has gone away, these should be
-relatively straightforward to fix.)
-
-IR1-4:
+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
+ unfortunately not a reliable way to get a timely response from
+ the SBCL maintainers)
+ In the course of trying to build a test case for an
+ application error, I encountered this behavior:
+ If you start up sbcl, and then lay on CTRL-C for a
+ minute or two, the lisp process will eventually say:
+ %PRIMITIVE HALT called; the party is over.
+ and throw you into the monitor. If I start up lisp,
+ attach to the process with strace, and then do the same
+ (abusive) thing, I get instead:
+ access failure in heap page not marked as write-protected
+ and the monitor again. I don't know enough to have the
+ faintest idea of what is going on here.
+ This is with sbcl 6.12, uname -a reports:
+ Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown
+ I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141
+ under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it:
+ it took more than two minutes (but less than five) for me.
+
+144:
+ (This was once known as IR1-4, but it lived on even after the
+ IR1 interpreter went to the big bit bucket in the sky.)
The system accepts DECLAIM in most places where DECLARE would be
accepted, without even issuing a warning. ANSI allows this, but since
it's fairly easy to mistype DECLAIM instead of DECLARE, and the
interpreter is gone, the system's notion of what's a top-level form
and what's not will remain too confused to fix this problem.]
-IR1-6:
- (another wishlist thing..) Reimplement DEFMACRO to be basically
- like DEFMACRO-MUNDANELY, just using EVAL-WHEN.
+145:
+ ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
+ FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
+ COMPLEX implementation didn't deal with this, and hasn't been
+ upgraded to do so. (This doesn't seem to be a high priority
+ conformance problem, since seems hard to construct useful code
+ where it matters.)
+
+146:
+ Floating point errors are reported poorly. E.g. on x86 OpenBSD
+ with sbcl-0.7.1,
+ * (expt 2.0 12777)
+ debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
+ An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
+ No traps are enabled? How can this be?
+ It should be possible to be much more specific (overflow, division
+ by zero, etc.) and of course the "How can this be?" should be fixable.
+
+147:
+ (reported by Alexey Dejneka sbcl-devel 2002-01-28)
+ Compiling a file containing
+ (deftype digit () '(member #\1))
+ (defun parse-num (string ind)
+ (flet ((digs ()
+ (let (old-index)
+ (if (and (< ind ind)
+ (typep (char string ind) 'digit))
+ nil))))))
+ in sbcl-0.7.1 causes the compiler to fail with
+ internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
+ This problem seems to have been introduced by the sbcl-0.pre7.* compiler
+ changes, since 0.pre7.73 and 0.6.13 don't suffer from it. A related
+ test case is
+ (defun parse-num (index)
+ (let (num x)
+ (flet ((digs ()
+ (setq num index))
+ (z ()
+ (let ()
+ (setq x nil))))
+ (when (and (digs) (digs)) x))))
+ In sbcl-0.7.1, this second test case failed with the same
+ internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
+ After the APD patches in sbcl-0.7.1.2 (new consistency check in
+ TARGET-IF-DESIRABLE, plus a fix in meta-vmdef.lisp to keep the
+ new consistency check from failing routinely) this second test case
+ failed in FIND-IN-PHYSENV instead. Fixes in sbcl-0.7.1.3 (not
+ closing over unreferenced variables) made this second test case
+ compile without error, but the original test case still fails.
+
+ Another way to get rid of the DEFTYPE without changing the symptom
+ of the bug is
+ (defvar *ch*)
+ (defun parse-num (string ind)
+ (flet ((digs ()
+ (let ()
+ (if (and (< ind ind)
+ (sb-int:memq *ch* '(#\1)))
+ nil))))))
+ In sbcl-0.7.1.3, this fails with
+ internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)"
+ The problem occurs while the inline expansion of MEMQ,
+ #<LAMBDA :%DEBUG-NAME "varargs entry point for SB-C::.ANONYMOUS.">
+ is being LET-converted after having its second REF deleted, leaving
+ it with only one entry in LEAF-REFS.
+
+148:
+ In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
+ (in-package :cl-user)
+ (defvar *thing*)
+ (defvar *zoom*)
+ (defstruct foo bar bletch)
+ (defun %zeep ()
+ (labels ((kidify1 (kid)
+ )
+ (kid-frob (kid)
+ (if *thing*
+ (setf sweptm
+ (m+ (frobnicate kid)
+ sweptm))
+ (kidify1 kid))))
+ (declare (inline kid-frob))
+ (map nil
+ #'kid-frob
+ (the simple-vector (foo-bar perd)))))
+ fails with
+ debugger invoked on condition of type TYPE-ERROR:
+ The value NIL is not of type SB-C::NODE.
+ The location of this failure has moved around as various related
+ 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.
+
+149:
+ (reported by Stig E Sandoe sbcl-devel 2002-02-02)
+ In sbcl-0.7.1.13, compiling a DEFCLASS FOO form isn't enough to make
+ the class known to the compiler for other forms compiled in the same
+ file, so bogus warnings "undefined type: FOO" are generated, e.g.
+ when compiling
+ (in-package :cl-user)
+ (defclass foo () ())
+ (defun bar (x)
+ (typep x 'foo))
+
+DEFUNCT CATEGORIES OF BUGS
+ IR1-#:
+ These numbers were used for bugs related to the old IR1
+ interpreter. The # values reached 6 before the category
+ was closed down.
\ No newline at end of file