X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=8ee489161546ea3434da88812abd4a9a1f974903;hb=34dd23563d2f5cf05c72b971da0d0b065a09bf2a;hp=12abb16b52860db7296b0572ba001344a5273c71;hpb=f1efc390c46d7b0054b504981b36baf928259ab6;p=sbcl.git diff --git a/BUGS b/BUGS index 12abb16..8ee4891 100644 --- a/BUGS +++ b/BUGS @@ -126,45 +126,9 @@ WORKAROUND: (Also, when this is fixed, we can enable the code in PROCLAIM which checks for incompatible FTYPE redeclarations.) -18: - from DTC on the CMU CL mailing list 25 Feb 2000: -;;; Compiler fails when this file is compiled. -;;; -;;; Problem shows up in delete-block within ir1util.lisp. The assertion -;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment))) -;;; fails within bind node branch. -;;; -;;; Note that if c::*check-consistency* is enabled then an un-reached -;;; entry is also reported. -;;; -(defun foo (val) - (declare (values nil)) - nil) -(defun bug (val) - (multiple-value-call - #'(lambda (res) - (block nil - (tagbody - loop - (when res - (return nil)) - (go loop)))) - (foo val)) - (catch 'ccc1 - (throw 'ccc1 - (block bbbb - (tagbody - - (let ((ttt #'(lambda () (go cccc)))) - (declare (special ttt)) - (return-from bbbb nil)) - - cccc - (return-from bbbb nil)))))) - 19: (I *think* this is a bug. It certainly seems like strange behavior. But - the ANSI spec is scary, dark, and deep..) + the ANSI spec is scary, dark, and deep.. -- WHN) (FORMAT NIL "~,1G" 1.4) => "1. " (FORMAT NIL "~3,1G" 1.4) => "1. " @@ -173,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)) @@ -191,24 +157,6 @@ WORKAROUND: Process inferior-lisp exited abnormally with code 1 I haven't noticed a repeatable case of this yet. -29: - some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling - (DEFUN BAR? (X) - (OR (NAR? X) - (BLOCK USED-BY-SOME-Y? - (FLET ((FROB (STK) - (DOLIST (Y STK) - (UNLESS (REJECTED? Y) - (RETURN-FROM USED-BY-SOME-Y? T))))) - (DECLARE (INLINE FROB)) - (FROB (RSTK X)) - (FROB (MRSTK X))) - NIL))) - gives - error in function SB-KERNEL:ASSERT-ERROR: - The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed. - This is still present in sbcl-0.6.8. - 31: In some cases the compiler believes type declarations on array elements without checking them, e.g. @@ -272,11 +220,6 @@ WORKAROUND: (Also, verify that the compiler handles declared function return types as assertions.) -38: - DEFMETHOD doesn't check the syntax of &REST argument lists properly, - accepting &REST even when it's not followed by an argument name: - (DEFMETHOD FOO ((X T) &REST) NIL) - 41: TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in (DEFTYPE INDEXOID () '(INTEGER 0 1000)) @@ -314,21 +257,24 @@ WORKAROUND: 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. @@ -390,11 +336,7 @@ WORKAROUND: 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. @@ -425,13 +367,6 @@ WORKAROUND: 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: - # 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 @@ -692,8 +627,8 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (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.) @@ -717,25 +652,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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 @@ -810,18 +726,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: ;; no problem, can just use the ordinary expansion `(function (setf ,place-function-name)))) -99: - DESCRIBE interacts poorly with *PRINT-CIRCLE*, e.g. the output from - (let ((*print-circle* t)) (describe (make-hash-table))) - is weird, - # is an . (EQL) - Its SIZE is 16. - Its REHASH-SIZE is 1.5. Its REHASH-THRESHOLD is . (1.0) - It holds 0 key/value pairs. - where the ". (EQL)" and ". (1.0)" substrings are screwups. - (This is likely a pretty-printer problem which happens to - be exercised by DESCRIBE, not actually a DESCRIBE problem.) - 100: There's apparently a bug in CEILING optimization which caused Douglas Crosher to patch the CMU CL version. Martin Atzmueller @@ -852,14 +756,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: /usr/stuff/sbcl/src/code/host-alieneval.lisp Created: Monday, March 12, 2001 07:47:43 AM CST -105: - (DESCRIBE 'STREAM-READ-BYTE) - -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: @@ -904,44 +800,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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: @@ -1144,25 +1002,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (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 @@ -1236,21 +1075,6 @@ Error in function C::GET-LAMBDA-TO-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, @@ -1282,30 +1106,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: still some functions named "hairy arg processor" and "SB-INT:&MORE processor". -139: - In sbcl-0.pre7.107, (DIRECTORY "*.*") is broken, as reported by - Nathan Froyd sbcl-devel 2001-12-28. - - Christophe Rhodes suggested (sbcl-devel 2001-12-30) converting - the MERGED-PATHNAME expression in DEFUN DIRECTORY to - (merged-pathname (merge-pathnames pathname - *default-pathname-defaults*)) - This looks right, and fixes this bug, but it interacts with the NODES - logic in %ENUMERATE-PATHNAMES to create a new bug, so that - (DIRECTORY "../**/*.*") no longer shows files in the current working - directory. Probably %ENUMERATE-PATHNAMES (or related logic like - %ENUMERATE-MATCHES) needs to be patched as well. - - Note: The MERGED-PATHNAME change changes behavior incompatibly, - making e.g. (DIRECTORY "*") no longer equivalent to (DIRECTORY "*.*"), - so deserves a NEWS entry. E.g. -* minor incompatible change (part of a bug fix by Christophe Rhodes - to DIRECTORY behavior): DIRECTORY no longer implicitly promotes - NIL slots of its pathname argument to :WILD, and in particular - asking for the contents of a directory, which you used to be able - to do without explicit wildcards, e.g. (DIRECTORY "/tmp/"), - now needs explicit wildcards, e.g. (DIRECTORY "/tmp/*.*"). - 140: (reported by Alexey Dejneka sbcl-devel 2002-01-03) @@ -1331,13 +1131,45 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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: +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 @@ -1351,6 +1183,111 @@ IR1-4: 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, + # + 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