X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=bdf4781ee70d76b8f73cf99a6b0df28b9a1b9717;hb=b767eae48831153473226b985511c8f7a3ef98c5;hp=e70a656c640a7996c0f0b593531c978c143a194f;hpb=510a9c48b7a80bf89ee54bdbd92519e76e8e178d;p=sbcl.git diff --git a/BUGS b/BUGS index e70a656..bdf4781 100644 --- a/BUGS +++ b/BUGS @@ -137,6 +137,8 @@ WORKAROUND: (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)) @@ -1059,20 +1061,6 @@ WORKAROUND: 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 - # 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.) - 135: Ideally, uninterning a symbol would allow it, and its associated FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, @@ -1188,9 +1176,150 @@ WORKAROUND: 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, + # + 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. + +150: + In sbcl-0.7.1.15, compiling this code + (let* () + (flet ((wufn () (glorp table1 4.9))) + (gleep *uustk* #'wufn "#1" (list))) + (if (eql (lo foomax 3.2)) + (values) + (error "not ~S" '(eql (lo foomax 3.2)))) + (values)) + causes a failure in SB-C::ADD-TEST-CONSTRAINTS: + The value NIL is not of type SB-C::CONTINUATION. + other notes: + * The problem appears to be tied to the way that EQL is given only + one argument, and goes away when we give EQL a second argument. + * CMU CL 18c has this problem too, exercised by + (compile nil + '(lambda () + (let* () + (flet ((wufn () (glorp table1 4.9))) + (gleep *uustk* #'wufn "#1" (list))) + (if (eql (lo foomax 3.2)) + (values) + (error "not ~S" '(eql (lo foomax 3.2)))) + (values)))) + +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 + # + +152: + Undefined functions are supposed to be reported as UNDEFINED-FUNCTION + conditions, inheriting from CELL-ERROR. Instead sbcl-0.7.1.19 reports + them as TYPE-ERRORs (reporting the problem as something not being + coerceable to a function). + +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. + + 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 + These labels were used for bugs related to the old IR1 interpreter. + The # values reached 6 before the category was closed down.