X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=cace3b33eb2077e5bdc060c83f8d0b59dba01511;hb=f1407e424f1063203af07d2e61ceef58515a4797;hp=c9216c72b871111f7123e7bbf44641e3757803af;hpb=e049902f5e7c30501d2dbb7a41d058a0c717fc1f;p=sbcl.git diff --git a/BUGS b/BUGS index c9216c7..cace3b3 100644 --- a/BUGS +++ b/BUGS @@ -42,7 +42,7 @@ KNOWN BUGS OF NO SPECIAL CLASS: program, even if you know or guess enough about the internals of SBCL to wager that this (undefined in ANSI) operation would be safe. -3: +3: "type checking of structure slots" a: ANSI specifies that a type mismatch in a structure slot initialization value should not cause a warning. @@ -84,19 +84,24 @@ WORKAROUND: an error may be signalled at read time and it would be good if SBCL did it. -6: - bogus warnings about undefined functions for magic functions like - SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files - like src/code/float.lisp. Fixing this will probably require - straightening out enough bootstrap consistency issues that - the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*. - Instead, the cross-compiler runs in a slightly flaky state - which is sane enough to compile SBCL itself, but which is - 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. + c: Reading of not initialized slot sometimes causes SEGV (for inline + accessors it is fixed, but out-of-line still do not perform type + check). + + d: + (declaim (optimize (safety 3) (speed 1) (space 1))) + (defstruct foo + x y) + (defstruct (stringwise-foo (:include foo + (x "x" :type simple-string) + (y "y" :type simple-string)))) + (defparameter *stringwise-foo* + (make-stringwise-foo)) + (setf (foo-x *stringwise-foo*) 0) + (defun frob-stringwise-foo (sf) + (aref (stringwise-foo-x sf) 0)) + (frob-stringwise-foo *stringwise-foo*) + SEGV. 7: The "compiling top-level form:" output ought to be condensed. @@ -141,16 +146,6 @@ WORKAROUND: (FORMAT NIL "~,1G" 1.4) => "1. " (FORMAT NIL "~3,1G" 1.4) => "1. " -20: - from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000: - (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)) - 27: Sometimes (SB-EXT:QUIT) fails with Argh! maximum interrupt nesting depth (4096) exceeded, exiting @@ -235,8 +230,8 @@ WORKAROUND: 45: a slew of floating-point-related errors reported by Peter Van Eynde on July 25, 2000: - b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and - should probably be 1.4012985e-45. In SBCL, + b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT on the x86 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, @@ -265,30 +260,6 @@ WORKAROUND: not a binary input stream, but instead cheerfully reads from character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). -47: - DEFCLASS bugs reported by Peter Van Eynde July 25, 2000: - d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead - causes a COMPILER-ERROR. - -51: - miscellaneous errors reported by Peter Van Eynde July 25, 2000: - a: (PROGN - (DEFGENERIC FOO02 (X)) - (DEFMETHOD FOO02 ((X NUMBER)) T) - (LET ((M (FIND-METHOD (FUNCTION FOO02) - NIL - (LIST (FIND-CLASS (QUOTE NUMBER)))))) - (REMOVE-METHOD (FUNCTION FOO02) M) - (DEFGENERIC FOO03 (X)) - (ADD-METHOD (FUNCTION FOO03) M))) - should give an error, but SBCL allows it. - -52: - It has been reported (e.g. by Peter Van Eynde) that there are - several metaobject protocol "errors". (In order to fix them, we might - need to document exactly what metaobject protocol specification - we're following -- the current code is just inherited from PCL.) - 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -353,18 +324,6 @@ WORKAROUND: (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to make the temporary filename less easily guessable) -82: - Functions are assigned names based on the context in which they're - defined. This is less than ideal for the functions which are - used to implement CLOS methods. E.g. the output of - (DESCRIBE 'PRINT-OBJECT) lists functions like - # - and - # - It would be better if these functions' names always identified - them as methods, and identified their generic functions and - specializers. - 83: RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though @@ -609,7 +568,6 @@ WORKAROUND: (note the space between the comma and the point) - 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately prominent SourceForge web/db bug tracking system, which is @@ -700,10 +658,8 @@ WORKAROUND: expansion, leaving garbage consisting of infinished blocks of the partially converted function.) -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) + (due to reordering of the compiler this example is compiled + successfully by 0.7.14, but the bug probably remains) 162: (reported by Robert E. Brown 2002-04-16) @@ -873,6 +829,28 @@ WORKAROUND: (INTEGER 1296 1296) ...)>)[:EXTERNAL] + In recent SBCL the following example also illustrates this bug: + + (time (compile + nil + '(lambda () + (declare (optimize (safety 3))) + (declare (optimize (compilation-speed 2))) + (declare (optimize (speed 1) (debug 1) (space 1))) + (let ((start 4)) + (declare (type (integer 0) start)) + (print (incf start 22)) + (print (incf start 26)) + (print (incf start 28))) + (let ((start 6)) + (declare (type (integer 0) start)) + (print (incf start 22)) + (print (incf start 26))) + (let ((start 10)) + (declare (type (integer 0) start)) + (print (incf start 22)) + (print (incf start 26)))))) + 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 @@ -901,65 +879,6 @@ WORKAROUND: 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." - b. What seemed like the same fundamental problem as bug 192a, but - was not fixed by the same (APD "more strict type checking - sbcl-devel 2002-08-97) patch: - (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 - - (see bug 203) - - c. (defun foo (x y) - (locally (declare (type fixnum x y)) - (+ x (* 2 y)))) - (foo 1.1 2) => 5.1 - -194: "no error from (THE REAL '(1 2 3)) in some cases" - fixed parts: - a. In sbcl-0.7.7.9, - (multiple-value-prog1 (progn (the real '(1 2 3)))) - returns (1 2 3) instead of signalling an error. This was fixed by - APD's "more strict type checking patch", but although the fixed - code (in sbcl-0.7.7.19) works (signals TYPE-ERROR) interactively, - it's difficult to write a regression test for it, because - (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3))))) - still returns (1 2 3). - still-broken parts: - b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3))))) - returns (1 2 3). (As above, this shows up when writing regression - tests for fixed-ness of part a.) - c. Also in sbcl-0.7.7.9, (IGNORE-ERRORS (THE REAL '(1 2 3))) => (1 2 3). - d. At the REPL, - (null (ignore-errors - (let ((arg1 1) - (arg2 (identity (the real #(1 2 3))))) - (if (< arg1 arg2) arg1 arg2)))) - => T - but putting the same expression inside (DEFUN FOO () ...), - (FOO) => NIL. - notes: - * Actually this entry is probably multiple bugs, as - Alexey Dejneka commented on sbcl-devel 2002-09-03:) - I don't think that placing these two bugs in one entry is - a good idea: they have different explanations. The second - (min 1 nil) is caused by flushing of unused code--IDENTITY - can do nothing with it. So it is really bug 122. The first - (min nil) is due to M-V-PROG1: substituting a continuation - for the result, it forgets about type assertion. The purpose - of IDENTITY is to save the restricted continuation from - inaccurate transformations. - * Alexey Dejneka pointed out that - (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3)))) - and - (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3)))) - work as they should. 201: "Incautious type inference from compound CONS types" (reported by APD sbcl-devel 2002-09-17) @@ -975,14 +894,6 @@ WORKAROUND: (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1" -203: - Compiler does not check THEs on unused values, e.g. in - - (progn (the real (list 1)) t) - - This situation may appear during optimizing away degenerate cases of - certain functions: see bug 192b. - 205: "environment issues in cross compiler" (These bugs have no impact on user code, but should be fixed or documented.) @@ -1155,15 +1066,6 @@ WORKAROUND: would be to put the check between evaluation of arguments, but it could be tricky to check result types of PROG1, IF etc. -228: "function-lambda-expression problems" - in sbcl-0.7.9.6x, from the REPL: - * (progn (declaim (inline foo)) (defun foo (x) x)) - FOO - * (function-lambda-expression #'foo) - (SB-C:LAMBDA-WITH-LEXENV NIL NIL NIL (X) (BLOCK FOO X)), NIL, FOO - but this first return value is not suitable for input to FUNCTION or - COMPILE, as required by ANSI. - 229: (subtypep 'function '(function)) => nil, t. @@ -1180,6 +1082,7 @@ WORKAROUND: (foo 4) => segmentation violation (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS) + (see also bug 236) b. (declaim (optimize (speed 2) (safety 3))) @@ -1189,8 +1092,124 @@ WORKAROUND: (+ x 2))) (foo 1d0 5) => segmentation violation -234: - (fixed in sbcl-0.7.10.36) +235: "type system and inline expansion" + a. + (declaim (ftype (function (cons) number) acc)) + (declaim (inline acc)) + (defun acc (c) + (the number (car c))) + + (defun foo (x y) + (values (locally (declare (optimize (safety 0))) + (acc x)) + (locally (declare (optimize (safety 3))) + (acc y)))) + + (foo '(nil) '(t)) => NIL, T. + + b. (reported by brown on #lisp 2003-01-21) + + (defun find-it (x) + (declare (optimize (speed 3) (safety 0))) + (declare (notinline mapcar)) + (let ((z (mapcar #'car x))) + (find 'foobar z))) + + Without (DECLARE (NOTINLINE MAPCAR)), Python cannot derive that Z is + LIST. + +237: "Environment arguments to type functions" + a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and + UPGRADED-COMPLEX-PART-TYPE now have an optional environment + argument, but they ignore it completely. This is almost + certainly not correct. + b. Also, the compiler's optimizers for TYPEP have not been informed + about the new argument; consequently, they will not transform + calls of the form (TYPEP 1 'INTEGER NIL), even though this is + just as optimizeable as (TYPEP 1 'INTEGER). + +238: "REPL compiler overenthusiasm for CLOS code" + From the REPL, + * (defclass foo () ()) + * (defmethod bar ((x foo) (foo foo)) (call-next-method)) + causes approximately 100 lines of code deletion notes. Some + discussion on this issue happened under the title 'Three "interesting" + bugs in PCL', resulting in a fix for this oververbosity from the + compiler proper; however, the problem persists in the interactor + because the notion of original source is not preserved: for the + compiler, the original source of the above expression is (DEFMETHOD + BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the + compiler gets its hands on the code needing compilation from the REPL, + it has been macroexpanded several times. + + A symptom of the same underlying problem, reported by Tony Martinez: + * (handler-case + (with-input-from-string (*query-io* " no") + (yes-or-no-p)) + (simple-type-error () 'error)) + ; in: LAMBDA NIL + ; (SB-KERNEL:FLOAT-WAIT) + ; + ; note: deleting unreachable code + ; compilation unit finished + ; printed 1 note + +241: "DEFCLASS mysteriously remembers uninterned accessor names." + (from tonyms on #lisp IRC 2003-02-25) + In sbcl-0.7.12.55, typing + (defclass foo () ((bar :accessor foo-bar))) + (profile foo-bar) + (unintern 'foo-bar) + (defclass foo () ((bar :accessor foo-bar))) + gives the error message + "#:FOO-BAR already names an ordinary function or a macro." + So it's somehow checking the uninterned old accessor name instead + of the new requested accessor name, which seems broken to me (WHN). + +242: "WRITE-SEQUENCE suboptimality" + (observed from clx performance) + In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type + (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type + (UNSIGNED-BYTE 8) will write to the stream one byte at a time, + rather than writing the sequence in one go, leading to severe + performance degradation. + +243: "STYLE-WARNING overenthusiasm for unused variables" + (observed from clx compilation) + In sbcl-0.7.14, in the presence of the macros + (DEFMACRO FOO (X) `(BAR ,X)) + (DEFMACRO BAR (X) (DECLARE (IGNORABLE X)) 'NIL) + somewhat surprising style warnings are emitted for + (COMPILE NIL '(LAMBDA (Y) (FOO Y))): + ; in: LAMBDA (Y) + ; (LAMBDA (Y) (FOO Y)) + ; + ; caught STYLE-WARNING: + ; The variable Y is defined but never used. + +245: bugs in disassembler + a. On X86 an immediate operand for IMUL is printed incorrectly. + b. On X86 operand size prefix is not recognized. + +246: "NTH-VALUE scaling problem" + NTH-VALUE's current implementation for constant integers scales in + compile-time as O(n^4), as indeed must the optional dispatch + mechanism on which it is implemented. While it is unlikely to + matter in real user code, it's still unpleasant to observe that + (NTH-VALUE 1000 (VALUES-LIST (MAKE-LIST 1001))) takes several hours + to compile. + +248: "reporting errors in type specifier syntax" + (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type + specifier". + +251: + (defun foo (&key (a :x)) + (declare (fixnum a)) + a) + + does not cause a warning. (BTW: old SBCL issued a warning, but for a + function, which was never called!) DEFUNCT CATEGORIES OF BUGS IR1-#: