X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=729c8d2e7a2c52892239aef52d19dab2ae3e166c;hb=9a2e730f74641e7de6ad4099111db92c5ad863bf;hp=2e4eab513fab8c4d9b865d1e774901485869f59a;hpb=b05f52060838600d14b5d8ad4604a61351dd7017;p=sbcl.git diff --git a/BUGS b/BUGS index 2e4eab5..729c8d2 100644 --- a/BUGS +++ b/BUGS @@ -1,4 +1,4 @@ -REPORTING BUGS +tREPORTING BUGS Bugs can be reported on the help mailing list sbcl-help@lists.sourceforge.net @@ -89,6 +89,9 @@ WORKAROUND: also unstable in several ways, including its inability to really grok function declarations. + As of sbcl-0.7.5, sbcl's cross-compiler does run with + *TYPE-SYSTEM-INITIALIZED*; however, this bug remains. + 7: The "compiling top-level form:" output ought to be condensed. Perhaps any number of such consecutive lines ought to turn into a @@ -126,45 +129,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,58 +140,17 @@ 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)) -22: - The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block", - says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used - inside "~<..~>" (without the colon modifier on the closing syntax). - However, SBCL doesn't do this: - * (FORMAT T "~" 12) - munge12egnum - NIL - 27: Sometimes (SB-EXT:QUIT) fails with Argh! maximum interrupt nesting depth (4096) exceeded, exiting 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. - (DECLAIM (OPTIMIZE (SAFETY 3) (SPEED 1) (SPACE 1))) - (DEFSTRUCT FOO A B) - (DEFUN BAR (X) - (DECLARE (TYPE (SIMPLE-ARRAY CONS 1) X)) - (WHEN (CONSP (AREF X 0)) - (PRINT (AREF X 0)))) - (BAR (VECTOR (MAKE-FOO :A 11 :B 12))) - prints - #S(FOO :A 11 :B 12) - in SBCL 0.6.5 (and also in CMU CL 18b). This does not happen for - all cases, e.g. the type assumption *is* checked if the array - elements are declared to be of some structure type instead of CONS. - 32: The printer doesn't report closures very well. This is true in CMU CL 18b as well: @@ -272,11 +198,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)) @@ -305,30 +226,27 @@ WORKAROUND: 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. @@ -345,9 +263,6 @@ WORKAROUND: 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. - f: (FLOAT-RADIX 2/3) should signal an error instead of - returning 2. - 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 @@ -355,10 +270,6 @@ WORKAROUND: TYPE-ERROR when handed e.g. the results of MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in the inappropriate positions, but doesn't. - j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8) - (QUOTE STRING))) - should probably signal an error instead of making a pathname with - a null byte in it. k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is not a binary input stream, but instead cheerfully reads from character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). @@ -377,28 +288,9 @@ WORKAROUND: 48: SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000: - a: (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal - PROGRAM-ERROR, but SBCL accepts it instead. - b: SYMBOL-MACROLET should refuse to bind something which is - declared as a global variable, signalling PROGRAM-ERROR. 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 @@ -425,27 +317,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 - problem seems to be that there are two relevant type methods for - the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and - INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is - called. This could be fixed, but type dispatch is messy and - confusing enough already, I don't want to complicate it further. - Perhaps someday we can make CLOS cross-compiled (instead of compiled - after bootstrapping) so that we don't need to have the type system - available before CLOS, and then we can rewrite the type methods to - CLOS methods, and then expressing the solutions to stuff like this - should become much more straightforward. -- WHN 2001-03-14 - 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -509,59 +380,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: the new output block should start indented 2 or more characters rightward of the correct location. -65: - (probably related to bug #70; maybe related to bug #109) - As reported by Carl Witty on submit@bugs.debian.org 1999-05-08, - compiling this file -(in-package "CL-USER") -(defun equal-terms (termx termy) - (labels - ((alpha-equal-bound-term-lists (listx listy) - (or (and (null listx) (null listy)) - (and listx listy - (let ((bindings-x (bindings-of-bound-term (car listx))) - (bindings-y (bindings-of-bound-term (car listy)))) - (if (and (null bindings-x) (null bindings-y)) - (alpha-equal-terms (term-of-bound-term (car listx)) - (term-of-bound-term (car listy))) - (and (= (length bindings-x) (length bindings-y)) - (prog2 - (enter-binding-pairs (bindings-of-bound-term (car listx)) - (bindings-of-bound-term (car listy))) - (alpha-equal-terms (term-of-bound-term (car listx)) - (term-of-bound-term (car listy))) - (exit-binding-pairs (bindings-of-bound-term (car listx)) - (bindings-of-bound-term (car listy))))))) - (alpha-equal-bound-term-lists (cdr listx) (cdr listy))))) - - (alpha-equal-terms (termx termy) - (if (and (variable-p termx) - (variable-p termy)) - (equal-bindings (id-of-variable-term termx) - (id-of-variable-term termy)) - (and (equal-operators-p (operator-of-term termx) (operator-of-term termy)) - (alpha-equal-bound-term-lists (bound-terms-of-term termx) - (bound-terms-of-term termy)))))) - - (or (eq termx termy) - (and termx termy - (with-variable-invocation (alpha-equal-terms termx termy)))))) - causes an assertion failure - The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER) - (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed. - - Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test - case with the same problem: -(defun parse-fssp-alignment () - ;; Given an FSSP alignment file named by the argument . . . - (labels ((get-fssp-char () - (get-fssp-char)) - (read-fssp-char () - (get-fssp-char))) - ;; Stub body, enough to tickle the bug. - (list (read-fssp-char) - (read-fssp-char)))) - 66: ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be a subtype of SEQUENCE, but CONCATENATE doesn't check this properly: @@ -579,6 +397,8 @@ Error in function C::GET-LAMBDA-TO-COMPILE: doesn't seem to exist for sequence types: (DEFTYPE BAR () 'SIMPLE-VECTOR) (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3) + See also bug #46a./b., and discussion and patch sbcl-devel and + cmucl-imp 2002-07 67: As reported by Winton Davies on a CMU CL mailing list 2000-01-10, @@ -586,53 +406,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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. - -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 - forms. E.g. - (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL)) - (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL)) - (LET ((ITEM (FIRST SEQ))) - (COND ((NULL SEQ) - (VALUES NIL NIL)) - ((FUNCALL TEST OBJ ITEM) - (VALUES VAL SEQ)) - (T - (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM)))))))) - (FIND-ITEM ITEM SEQUENCE TEST))) - from David Young's bug report on cmucl-help@cons.org 30 Nov 2000 - causes sbcl-0.6.9 to fail with - error in function SB-KERNEL:ASSERT-ERROR: - The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER) - (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. @@ -682,9 +455,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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)) @@ -692,50 +462,11 @@ 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.) -90: - a latent cross-compilation/bootstrapping bug: The cross-compilation - host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp - and possibly elsewhere. Instead, we should use the target system's - CHAR-CODE-LIMIT. This will probably cause problems if we try to - bootstrap on a system which uses a different value of CHAR-CODE-LIMIT - than SBCL does. - -91: - (subtypep '(or (integer -1 1) - unsigned-byte) - '(or (rational -1 7) - unsigned-byte - (integer -1 1))) => NIL,T - An analogous problem with SINGLE-FLOAT and REAL types was fixed in - sbcl-0.6.11.22, but some peculiarites of the RATIO type make it - awkward to generalize the fix to INTEGER and RATIONAL. It's not - 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 @@ -772,11 +503,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: GC, so that thereafter memory usage can never be reduced below that level. -96: - The TRACE facility can't be used on some kinds of functions. - (Basically, the breakpoint facility was incompletely implemented - in the X86 port of CMU CL, and hasn't been fixed in SBCL.) - 98: In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU CL), out-of-line structure slot setters are horribly inefficient @@ -810,18 +536,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 @@ -831,15 +545,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: the first time around, until regression tests are written I'm not comfortable merging the patches in the CVS version of SBCL. -102: - As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI - requires that SYMBOL-MACROLET refuse to rebind special variables, - but SBCL doesn't do this. (Also as reported by AL in the same - message, SBCL depended on this nonconforming behavior to build - itself, because of the way that **CURRENT-SEGMENT** was implemented. - As of sbcl-0.6.12.x, this dependence on the nonconforming behavior - has been fixed, but the nonconforming behavior remains.) - 104: (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list incorrectly: @@ -852,14 +557,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: @@ -867,25 +564,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: time trying to GC afterwards. Surely there's some more economical way to implement (ROOM T). -109: - reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs - collection: - ;;; This file fails to compile. - ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file. - (in-package :cl-user) - (defun tst2 () - (labels - ((eff (&key trouble) - (eff) - ;; nil - ;; Uncomment and it works - )) - (eff))) - In SBCL 0.6.12.42, the problem is - internal error, failed AVER: - "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER) - (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))" - 110: reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs collection: @@ -904,44 +582,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: @@ -1019,19 +659,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: Raymond Toy comments that this is tricky on the X86 since its FPU uses 80-bit precision internally. -120a: - The compiler incorrectly figures the return type of - (DEFUN FOO (FRAME UP-FRAME) - (IF (OR (NOT FRAME) - T) - FRAME - "BAR")) - as NIL. - - This problem exists in CMU CL 18c too. When I reported it on - cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with - a partial explanation, but no fix has been found yet. - 120b: Even in sbcl-0.pre7.x, which is supposed to be free of the old non-ANSI behavior of treating the function return type inferred @@ -1058,18 +685,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: #+NIL) and I'd like to go back to see whether this really is a compiler bug before I delete this BUGS entry. -123: - The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly - (IN-PACKAGE :SB-KERNEL) - (TYPE= (SPECIFIER-TYPE '(VECTOR T)) - (SPECIFIER-TYPE '(VECTOR UNDEFTYPE))) - Then because of this, the compiler bogusly optimizes - (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1)) - to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to - NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained - about type mismatches (probably harmlessly, another instance of bug 117); - and then cold init died with a segmentation fault. - 124: As of version 0.pre7.14, SBCL's implementation of MACROLET makes the entire lexical environment at the point of MACROLET available @@ -1128,9 +743,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: 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 @@ -1144,25 +756,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 @@ -1222,35 +815,6 @@ Error in function C::GET-LAMBDA-TO-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 - # 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, @@ -1269,119 +833,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE: (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". - -138: - a pair of cross-compiler bugs in sbcl-0.pre7.107 - -138a: - $ cat > /tmp/bug138.lisp << EOF - (in-package "SB!KERNEL") - (defun f-c-l (name parent-types) - (let* ((cpl (mapcar (lambda (x) - (condition-class-cpl x)) - parent-types)) - (new-inherits - (concatenate 'simple-vector - (layout-inherits cond-layout)))) - (if (not (mismatch (layout-inherits olayout) new-inherits)) - olayout - (make-layout)))) - EOF - $ sbcl --core output/after-xc.core - ... - * (target-compile-file "/tmp/bug138.lisp") - ... - internal error, failed AVER: - "(COMMON-LISP:MEMBER SB!C::FUN (SB!C::COMPONENT-LAMBDAS SB!C:COMPONENT))" - - It seems as though this xc bug is likely to correspond to a bug in the - ordinary compiler, but I haven't yet found a test case which causes - this problem in the ordinary compiler. - - related weirdness: Using #'(LAMBDA (X) ...) instead of (LAMBDA (X) ...) - makes the assertion failure go away. - -138b: - Even when you relax the AVER that fails in 138a, there's another - problem cross-compiling the same code: - internal error, failed AVER: - "(COMMON-LISP:ZEROP - (COMMON-LISP:HASH-TABLE-COUNT - (SB!FASL::FASL-OUTPUT-PATCH-TABLE SB!FASL:FASL-OUTPUT)))" - - The same problem appears in the simpler test case - (in-package "SB!KERNEL") - (defun f-c-l () - (let ((cpl (foo (lambda (x) - (condition-class-cpl x)))) - (new-inherits (layout-inherits cond-layout))) - (layout-inherits olayout))) - - Changing CONDITION-CLASS-CPL or (either of the calls to) LAYOUT-INHERITS - to arbitrary nonmagic not-defined-yet just-do-a-full-call functions makes - the problem go away. Also, even in this simpler test case which fails - on a very different AVER, the 138a weirdness about s/(lambda/#'(lambda/ - making the problem go away is preserved. - - I still haven't found any way to make this happen in the ordinary - (not cross-) SBCL compiler, nor in CMU CL. - -138c: - In sbcl-0.pre7.111 I added an assertion upstream, in IR2-CONVERT-CLOSURE, - which fails for the test case above but doesn't keep the system - from cross-compiling itself or passing its tests. - - I traced IR1-CONVERT-LAMBDA (with :PRINT *CURRENT-COMPONENT*) - and tracing various COMPONENT-manipulating functions like - FIND-INITIAL-DFO, DFO-SCAVENGE-DEPENDENCY-GRAPH, - JOIN-COMPONENTS, LOCALL-ANALYZE-COMPONENT, etc. From that, - it looks as though the problem is that IR1-CONVERT-LAMBDA - is being called by MAKE-EXTERNAL-ENTRY-POINT to - create the mislaid LAMBDA in an environment set up by - WITH-BELATED-IR1-ENVIRONMENT which has *CURRENT-COMPONENT* set - to a component which is never seen again, and specifically never - passed to LOCALL-ANALYZE-COMPONENT or JOIN-COMPONENTS, so that - its NEW-FUNS list (where the mislaid LAMBDA is waiting patiently) - gets lost. Thus, the LAMBDA is essentially being written into never - never land. But I haven't figured out why. *CURRENT-COMPONENT* is set - wrong? Something later on is dropping the ball and neglecting - to look at all the components it should? Something else? - -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) @@ -1408,13 +859,50 @@ 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: + 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 + 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 @@ -1428,6 +916,480 @@ 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. + + See also bugs #45.c and #183 + +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. + +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. + +157: + Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and + UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. + (reported by Alexey Dejneka sbcl-devel 2002-04-12) + +162: + (reported by Robert E. Brown 2002-04-16) + When a function is called with too few arguments, causing the + debugger to be entered, the uninitialized slots in the bad call frame + seem to cause GCish problems, being interpreted as tagged data even + though they're not. In particular, executing ROOM in the + debugger at that point causes AVER failures: + * (machine-type) + "X86" + * (lisp-implementation-version) + "0.7.2.12" + * (typep 10) + ... + 0] (room) + ... + failed AVER: "(SAP= CURRENT END)" + (Christophe Rhodes reports that this doesn't occur on the SPARC, which + isn't too surprising since there are many differences in stack + implementation and GC conservatism between the X86 and other ports.) + +166: + Compiling + (in-package :cl-user) + (defstruct uustk) + (defmethod permanentize ((uustk uustk)) + (flet ((frob (hash-table test-for-deletion) + ) + (obj-entry.stale? (oe) + (destructuring-bind (key . datum) oe + (declare (type simple-vector key)) + (deny0 (void? datum)) + (some #'stale? key)))) + (declare (inline frob obj-entry.stale?)) + (frob (uustk.args-hash->obj-alist uustk) + #'obj-entry.stale?) + (frob (uustk.hash->memoized-objs-list uustk) + #'objs.stale?)) + (call-next-method)) + in sbcl-0.7.3.11 causes an assertion failure, + failed AVER: + "(NOT +(AND (NULL (BLOCK-SUCC B)) + (NOT (BLOCK-DELETE-P B)) + (NOT (EQ B (COMPONENT-HEAD #)))))" + +167: + In sbcl-0.7.3.11, compiling the (illegal) code + (in-package :cl-user) + (defmethod prove ((uustk uustk)) + (zap ((frob () nil)) + (frob))) + gives the (not terribly clear) error message + ; caught ERROR: + ; (during macroexpansion of (DEFMETHOD PROVE ...)) + ; can't get template for (FROB NIL NIL) + The problem seems to be that the code walker used by the DEFMETHOD + macro is unhappy with the illegal syntax in the method body, and + is giving an unclear error message. + +168: + (reported by Dan Barlow on sbcl-devel 2002-05-10) + In sbcl-0.7.3.12, doing + (defstruct foo bar baz) + (compile nil (lambda (x) (or x (foo-baz x)))) + gives an error + debugger invoked on condition of type SB-INT:BUG: + full call to SB-KERNEL:%INSTANCE-REF + This is probably a bug in SBCL itself. [...] + Since this is a reasonable user error, it shouldn't be reported as + an SBCL bug. + +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. + +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) + +185: "top-level forms at the REPL" + * (locally (defstruct foo (a 0 :type fixnum))) + gives an error: + ; caught ERROR: + ; (in macroexpansion of (SB-KERNEL::%DELAYED-GET-COMPILER-LAYOUT BAR)) + however, compiling and loading the same expression in a file works + as expected. + +187: "type inference confusion around DEFTRANSFORM time" + (reported even more verbosely on sbcl-devel 2002-06-28 as "strange + bug in DEFTRANSFORM") + After the file below is compiled and loaded in sbcl-0.7.5, executing + (TCX (MAKE-ARRAY 4 :FILL-POINTER 2) 0) + at the REPL returns an adjustable vector, which is wrong. Presumably + somehow the DERIVE-TYPE information for the output values of %WAD is + being mispropagated as a type constraint on the input values of %WAD, + and so causing the type test to be optimized away. It's unclear how + hand-expanding the DEFTRANSFORM would change this, but it suggests + the DEFTRANSFORM machinery (or at least the way DEFTRANSFORMs are + invoked at a particular phase) is involved. + (cl:in-package :sb-c) + (eval-when (:compile-toplevel) + ;;; standin for %DATA-VECTOR-AND-INDEX + (defknown %dvai (array index) + (values t t) + (foldable flushable)) + (deftransform %dvai ((array index) + (vector t) + * + :important t) + (let* ((atype (continuation-type array)) + (eltype (array-type-specialized-element-type atype))) + (when (eq eltype *wild-type*) + (give-up-ir1-transform + "specialized array element type not known at compile-time")) + (when (not (array-type-complexp atype)) + (give-up-ir1-transform "SIMPLE array!")) + `(if (array-header-p array) + (%wad array index nil) + (values array index)))) + ;;; standin for %WITH-ARRAY-DATA + (defknown %wad (array index (or index null)) + (values (simple-array * (*)) index index index) + (foldable flushable)) + ;;; (Commenting out this optimizer causes the bug to go away.) + (defoptimizer (%wad derive-type) ((array start end)) + (let ((atype (continuation-type array))) + (when (array-type-p atype) + (values-specifier-type + `(values (simple-array ,(type-specifier + (array-type-specialized-element-type atype)) + (*)) + index index index))))) + ) ; EVAL-WHEN + (defun %wad (array start end) + (format t "~&in %WAD~%") + (%with-array-data array start end)) + (cl:in-package :cl-user) + (defun tcx (v i) + (declare (type (vector t) v)) + (declare (notinline sb-kernel::%with-array-data)) + ;; (Hand-expending DEFTRANSFORM %DVAI here also causes the bug to + ;; go away.) + (sb-c::%dvai v i)) + +188: "compiler performance fiasco involving type inference and UNION-TYPE" + (In sbcl-0.7.6.10, DEFTRANSFORM CONCATENATE was commented out until this + bug could be fixed properly, so you won't see the bug unless you restore + the DEFTRANSFORM by hand.) In sbcl-0.7.5.11 on a 700 MHz Pentium III, + (time (compile + nil + '(lambda () + (declare (optimize (safety 3))) + (declare (optimize (compilation-speed 2))) + (declare (optimize (speed 1) (debug 1) (space 1))) + (let ((fn "if-this-file-exists-the-universe-is-strange")) + (load fn :if-does-not-exist nil) + (load (concatenate 'string fn ".lisp") :if-does-not-exist nil) + (load (concatenate 'string fn ".fasl") :if-does-not-exist nil) + (load (concatenate 'string fn ".misc-garbage") + :if-does-not-exist nil))))) + reports + 134.552 seconds of real time + 133.35156 seconds of user run time + 0.03125 seconds of system run time + [Run times include 2.787 seconds GC run time.] + 0 page faults and + 246883368 bytes consed. + BACKTRACE from Ctrl-C in the compilation shows that the compiler is + thinking about type relationships involving types like + #)[:EXTERNAL] + +190: "PPC/Linux pipe? buffer? bug" + In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs + on the PPC/Linux platform, waiting for a zombie env process. This + is a classic symptom of buffer filling and deadlock, but it seems + only sporadically reproducible. + +191: "Miscellaneous PCL deficiencies" + (reported by Alexey Dejneka sbcl-devel 2002-08-04) + a. DEFCLASS does not inform the compiler about generated + functions. Compiling a file with + (DEFCLASS A-CLASS () + ((A-CLASS-X))) + (DEFUN A-CLASS-X (A) + (WITH-SLOTS (A-CLASS-X) A + A-CLASS-X)) + results in a STYLE-WARNING: + undefined-function + SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER| + + APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre + Mai points out that the declamation of functions is in fact + incorrect in some cases (most notably for structure + classes). This means that at present erroneous attempts to use + WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS + won't get the corresponding STYLE-WARNING. + c. the examples in CLHS 7.6.5.1 (regarding generic function lambda + lists and &KEY arguments) do not signal errors when they should. + +192: "Python treats free type declarations as promises." + a. original report by Alexey Dejneka (on sbcl-devel 2002-08-26): + (declaim (optimize (speed 0) (safety 3))) + (defun f (x) + (declare (real x)) + (+ x + (locally (declare (single-float x)) + (sin x)))) + Now (F NIL) correctly gives a type error, but (F 100) gives + a segmentation violation. + b. same fundamental problem in a different way, easy to stumble + across if you mistype and declare the wrong index in + (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)): + (declaim (optimize (speed 1) (safety 3))) + (defun trust-assertion (i) + (dotimes (j i) + (declare (type (mod 4) i)) ; when commented out, behavior changes! + (unless (< i 5) + (print j)))) + (trust-assertion 6) ; prints nothing unless DECLARE is commented out + +193: "unhelpful CLOS error reporting when the primary method is missing" + In sbcl-0.7.7, when + (defmethod foo :before ((x t)) (print x)) + is the only method defined on FOO, the error reporting when e.g. + (foo 12) + is relatively unhelpful: + There is no primary method for the generic function + #. + with the offending argument nowhere visible in the backtrace. This + continues even if there *are* primary methods, just not for the + specified arg type, e.g. + (defmethod foo ((x character)) (print x)) + (defmethod foo ((x string)) (print x)) + (defmethod foo ((x pathname)) ...) + In that case it could be very helpful to know what argument value is + falling through the cracks of the defined primary methods, but the + error message stays the same (even BACKTRACE doesn't tell you what the + bad argument value is). + +194: "no error from (THE REAL '(1 2 3)) in some cases" + In sbcl-0.7.7.9, + (multiple-value-prog1 (progn (the real '(1 2 3)))) + returns (1 2 3) instead of signalling an error. Also in sbcl-0.7.7.9, + a more complicated instance of this bug kept + (IGNORE-ERRORS (MIN '(1 2 3))) from returning NIL as it should when + the MIN source transform expanded to (THE REAL '(1 2 3)), because + (IGNORE-ERRORS (THE REAL '(1 2 3))) returns (1 2 3). + Alexey Dejneka pointed out that + (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3)))) works as it should. + (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3)))) also works as it should. + Perhaps this is another case of VALUES type intersections behaving + in non-useful ways? + When I (WHN) tried to use the VALUES trick to work around this bug + in the MIN source transform, it didn't work for + (assert (null (ignore-errors (min 1 #(1 2 3))))) + Hand-expanding the source transform, I get + (assert (null (ignore-errors + (let ((arg1 1) + (arg2 (identity (the real #(1 2 3))))) + (if (< arg1 arg2) arg1 arg2))))) + which fails (i.e. the assertion fails, because the IGNORE-ERRORS + doesn't report MIN signalling a type error). At the REPL + (null (ignore-errors + (let ((arg1 1) + (arg2 (identity (the real #(1 2 3))))) + (if (< arg1 arg2) arg1 arg2)))) + => T + but when this expression is used as the body of (DEFUN FOO () ...) + then (FOO)=>NIL. + +195: "confusing reporting of not-a-REAL TYPE-ERRORs from THE REAL" + In sbcl-0.7.7.10, (THE REAL #(1 2 3)) signals a type error which + prints as "This is not a (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL)". + The (OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL) representation of + REAL is unnecessarily confusing, especially since it relies on + internal implementation knowledge that even with SHORT-FLOAT + and LONG-FLOAT left out of the union, this type is equal to REAL. + So it'd be better just to say "This is not a REAL". + +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.