(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))
ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
(and now SBCL) interpret them as legal types.
-44:
- ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
- CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
- list, and it is probably possible to use substantially the same
- patches to add it to SBCL.
-
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.
c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
it binds is declared SPECIAL inside.
-50:
- type system errors reported by Peter Van Eynde July 25, 2000:
- c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
- 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.
- 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.
-
51:
miscellaneous errors reported by Peter Van Eynde July 25, 2000:
a: (PROGN
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
it should probably look at the class name, the way that it does
for STRUCTURE-OBJECTs.
-69:
- As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
- > There remains one issue, that is a bug in SBCL:
- > According to my interpretation of the spec, the ":" and "@" modifiers
- > should appear _after_ the comma-seperated arguments.
- > Well, SBCL (and CMUCL for that matter) accept
- > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) " 1"))
- > where the correct way (IMHO) should be
- > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) " 1"))
- Probably SBCL should stop accepting the "~:8D"-style format arguments,
- or at least issue a warning.
-
70:
(probably related to bug #65; maybe related to bug #109)
The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
it would decrease efficiency more than is probably necessary. Perhaps
using some sort of accept/reject method would be better.
-84:
- (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
-
85:
Internally the compiler sometimes evaluates
(sb-kernel:type/= (specifier-type '*) (specifier-type t))
(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
arguments in FLET/LABELS: it might be an old Python bug which is
only exercised by the new arrangement of the SBCL compiler.)
-132:
- Trying to compile
- (DEFUN FOO () (CATCH 0 (PRINT 1331)))
- gives an error
- #<SB-C:TN '0!1> is not valid as the second argument to VOP:
- SB-C:MAKE-CATCH-BLOCK,
- since the TN's primitive type SB-VM::POSITIVE-FIXNUM doesn't allow
- any of the SCs allowed by the operand restriction:
- (SB-VM::DESCRIPTOR-REG)
- The (CATCH 0 ...) construct is bad style (because of unportability
- of EQ testing of numbers) but it is legal, and shouldn't cause an
- 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,
T
T
-
-KNOWN BUGS RELATED TO THE IR1 INTERPRETER
-
-(Now that the IR1 interpreter has gone away, these should be
-relatively straightforward to fix.)
-
-IR1-4:
+ 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.
+
+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"
+
+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.
+
+151:
+ From the ANSI description of GET-DISPATCH-MACRO-CHARACTER, it
+ should return NIL when there is no definition, e.g.
+ (GET-DISPATCH-MACRO-CHARACTER #\# #\{) => NIL
+ Instead, in sbcl-0.7.1.17 it returns
+ #<FUNCTION "top level local call SB!IMPL::DISPATCH-CHAR-ERROR">
+
+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.
+
+154:
+ There's some sort of problem with aborting back out of the debugger
+ after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases
+ telling the debugger to ABORT doesn't get you back to the main REPL,
+ but instead just gives you another stack exhaustion error. The problem
+ doesn't occur in the trivial case
+ * (defun frob () (frob) (frob))
+ FROB
+ * (frob)
+ but it has happened in more complicated cases (which I haven't
+ figured out how to reproduce).
+
+155:
+ Executing
+ (defclass standard-gadget (basic-gadget) ())
+ (defclass basic-gadget () ())
+ gives an error:
+ The slot SB-PCL::DIRECT-SUPERCLASSES is unbound in the
+ object #<SB-PCL::STANDARD-CLASS "unbound">.
+ (reported by Brian Spilsbury sbcl-devel 2002-04-09)
+
+DEFUNCT CATEGORIES OF BUGS
+ IR1-#:
+ These labels were used for bugs related to the old IR1 interpreter.
+ The # values reached 6 before the category was closed down.
projects / sbcl.git / blobdiff