X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=729c8d2e7a2c52892239aef52d19dab2ae3e166c;hb=9a2e730f74641e7de6ad4099111db92c5ad863bf;hp=58bd328a59599e721f2e2cf1fc523078f8018cbf;hpb=05f01eeac89abd78d5d16c04bf31f0b1b0076213;p=sbcl.git diff --git a/BUGS b/BUGS index 58bd328..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 @@ -285,10 +288,6 @@ 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. @@ -381,59 +380,6 @@ WORKAROUND: 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: @@ -451,6 +397,8 @@ WORKAROUND: 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, @@ -458,27 +406,6 @@ WORKAROUND: crashes SBCL. In general tracing anything which is used in the implementation of TRACE is likely to have the same problem. -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. - 72: (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms. @@ -540,14 +467,6 @@ WORKAROUND: (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. - 94a: Inconsistencies between derived and declared VALUES return types for DEFUN aren't checked very well. E.g. the logic which successfully @@ -626,15 +545,6 @@ WORKAROUND: 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.7.3.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: @@ -654,25 +564,6 @@ WORKAROUND: 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: @@ -768,19 +659,6 @@ WORKAROUND: 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 @@ -807,18 +685,6 @@ WORKAROUND: #+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 @@ -1068,6 +934,8 @@ WORKAROUND: 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) @@ -1113,18 +981,6 @@ WORKAROUND: 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). - 157: Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. @@ -1150,27 +1006,6 @@ WORKAROUND: isn't too surprising since there are many differences in stack implementation and GC conservatism between the X86 and other ports.) -165: - Array types with element-types of some unknown type are falsely being - assumed to be of type (ARRAY T) by the compiler in some cases. The - following code demonstrates the problem: - - (defun foo (x) - (declare (type (vector bar) x)) - (aref x 1)) - (deftype bar () 'single-float) - (foo (make-array 3 :element-type 'bar)) - -> TYPE-ERROR "The value #(0.0 0.0 0.0) is not of type (VECTOR BAR)." - (typep (make-array 3 :element-type 'bar) '(vector bar)) - -> T - - The easy solution is to make the functions which depend on knowing - the upgraded-array-element-type (in compiler/array-tran and - compiler/generic/vm-tran as of sbcl-0.7.3.x) be slightly smarter about - unknown types; an alternative is to have the - specialized-element-type slot in the ARRAY-TYPE structure be - *WILD-TYPE* for UNKNOWN-TYPE element types. - 166: Compiling (in-package :cl-user) @@ -1344,12 +1179,6 @@ WORKAROUND: :ACCRUED-EXCEPTIONS (:INEXACT) :FAST-MODE NIL) -184: "division by zero becomes frozen into RATIO" - (reported by Wolfhard Buss on cmucl-imp 18 Jun 2002, fails on - sbcl-0.7.4.39 too) - * (/ 1 (/ 3 2) 0) - 1/0 - 185: "top-level forms at the REPL" * (locally (defstruct foo (a 0 :type fixnum))) gives an error: @@ -1416,7 +1245,9 @@ WORKAROUND: (sb-c::%dvai v i)) 188: "compiler performance fiasco involving type inference and UNION-TYPE" - In sbcl-0.7.5.11 on a 700 MHz Pentium III, + (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 () @@ -1450,8 +1281,113 @@ WORKAROUND: (INTEGER 1296 1296) ...)>)[:EXTERNAL] -(189: "ignored NOTINLINE for functions defined by FLET or LABELS") - (fixed in sbcl-0.7.6.3) +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-#: