X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=84357b16759532a7540a0ce62020e8908eba92cd;hb=51c5280a4b41f8c51d434643cde3e18af4113473;hp=109b0c9a584a672c8edd34c52a52e342b8c2fb6a;hpb=5abc2bce01b292db23f3aca340243a65d9a920d8;p=sbcl.git diff --git a/BUGS b/BUGS index 109b0c9..84357b1 100644 --- a/BUGS +++ b/BUGS @@ -84,47 +84,13 @@ WORKAROUND: an error may be signalled at read time and it would be good if SBCL did it. - 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. + d: (fixed in 0.8.1.5) 7: The "compiling top-level form:" output ought to be condensed. Perhaps any number of such consecutive lines ought to turn into a single "compiling top-level forms:" line. -10: - The way that the compiler munges types with arguments together - with types with no arguments (in e.g. TYPE-EXPAND) leads to - weirdness visible to the user: - (DEFTYPE FOO () 'FIXNUM) - (TYPEP 11 'FOO) => T - (TYPEP 11 '(FOO)) => T, which seems weird - (TYPEP 11 'FIXNUM) => T - (TYPEP 11 '(FIXNUM)) signals an error, as it should - The situation is complicated by the presence of Common Lisp types - like UNSIGNED-BYTE (which can either be used in list form or alone) - so I'm not 100% sure that the behavior above is actually illegal. - But I'm 90+% sure, and the following related behavior, - (TYPEP 11 'AND) => T - treating the bare symbol AND as equivalent to '(AND), is specifically - forbidden (by the ANSI specification of the AND type). - 11: It would be nice if the caught ERROR: @@ -134,12 +100,6 @@ WORKAROUND: (during macroexpansion of IN-PACKAGE, during macroexpansion of DEFFOO) -15: - (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL) - '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T - (Also, when this is fixed, we can enable the code in PROCLAIM which - checks for incompatible FTYPE redeclarations.) - 19: (I *think* this is a bug. It certainly seems like strange behavior. But the ANSI spec is scary, dark, and deep.. -- WHN) @@ -207,22 +167,9 @@ WORKAROUND: so they could be supported after all. Very likely SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too. -43: - (as discussed by Douglas Crosher on the cmucl-imp mailing list ca. - Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same - issue with 'union, 'and, 'or etc. So even though according to the - ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL - (and now SBCL) interpret them as legal types. - 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 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, - and LEAST-NEGATIVE-LONG-FLOAT. c: Many expressions generate floating infinity on x86/Linux: (/ 1 0.0) (/ 1 0.0d0) @@ -241,14 +188,13 @@ WORKAROUND: 46: type safety errors reported by Peter Van Eynde July 25, 2000: - c: (COERCE 'AND 'FUNCTION) returns something related to - (MACRO-FUNCTION 'AND), but ANSI says it should raise an error. 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"). 60: The debugger LIST-LOCATIONS command doesn't work properly. + (How should it work properly?) 61: Compiling and loading @@ -271,12 +217,6 @@ WORKAROUND: crashes SBCL. In general tracing anything which is used in the implementation of TRACE is likely to have the same problem. -75: - As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000, - ANSI says that WITH-OUTPUT-TO-STRING should have a keyword - :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for - WITH-OUTPUT-TO-STRING. - 78: ANSI says in one place that type declarations can be abbreviated even when the type name is not a symbol, e.g. @@ -324,34 +264,6 @@ WORKAROUND: holding... * is not equivalent to T in many cases, such as (VECTOR *) /= (VECTOR T). -94a: - Inconsistencies between derived and declared VALUES return types for - DEFUN aren't checked very well. E.g. the logic which successfully - catches problems like - (declaim (ftype (function (fixnum) float) foo)) - (defun foo (x) - (declare (type integer x)) - (values x)) ; wrong return type, detected, gives warning, good! - fails to catch - (declaim (ftype (function (t) (values t t)) bar)) - (defun bar (x) - (values x)) ; wrong number of return values, no warning, bad! - The cause of this is seems to be that (1) the internal function - VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its - arguments symmetrically, and (2) when the type checking code was - written back when when SBCL's code was still CMU CL, the intent - was that this case - (declaim (ftype (function (t) t) bar)) - (defun bar (x) - (values x x)) ; wrong number of return values; should give warning? - not be warned for, because a two-valued return value is considered - to be compatible with callers who expects a single value to be - returned. That intent is probably not appropriate for modern ANSI - Common Lisp, but fixing this might be complicated because of other - divergences between auld-style and new-style handling of - multiple-VALUES types. (Some issues related to this were discussed - on cmucl-imp at some length sometime in 2000.) - 95: The facility for dumping a running Lisp image to disk gets confused when run without the PURIFY option, and creates an unnecessarily large @@ -368,20 +280,31 @@ WORKAROUND: so the compiler doesn't compile the type test into code, but instead just saves the type in a lexical closure and interprets it at runtime. - A proper solution involves deciding whether it's really worth - saving space by implementing structure slot accessors as closures. - (If it's not worth it, the problem vanishes automatically. If it - is worth it, there are hacks we could use to force type tests to - be compiled anyway, and even shared. E.g. we could implement - an EQUAL hash table mapping from types to compiled type tests, - and save the appropriate compiled type test as part of each lexical - closure; or we could make the lexical closures be placeholders - which overwrite their old definition as a lexical closure with - a new compiled definition the first time that they're called.) - As a workaround for the problem, #'(SETF FOO) expressions can - be replaced with (EFFICIENT-SETF-FUNCTION FOO), where + To exercise the problem, compile and load + (cl:in-package :cl-user) + (defstruct foo + (bar (error "missing") :type bar)) + (defvar *foo*) + (defun wastrel1 (x) + (loop (setf (foo-bar *foo*) x))) + (defstruct bar) + (defvar *bar* (make-bar)) + (defvar *foo* (make-foo :bar *bar*)) + (defvar *setf-foo-bar* #'(setf foo-bar)) + (defun wastrel2 (x) + (loop (funcall *setf-foo-bar* x *foo*))) + then run (WASTREL1 *BAR*) or (WASTREL2 *BAR*), hit Ctrl-C, and + use BACKTRACE, to see it's spending all essentially all its time + in %TYPEP and VALUES-SPECIFIER-TYPE and so forth. + One possible solution would be simply to give up on + representing structure slot accessors as functions, and represent + them as macroexpansions instead. This can be inconvenient for users, + but it's not clear that it's worse than trying to help by expanding + into a horribly inefficient implementation. + As a workaround for the problem, #'(SETF FOO) expressions + can be replaced with (EFFICIENT-SETF-FUNCTION FOO), where (defmacro efficient-setf-function (place-function-name) - (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name) + (or #+sbcl (and (sb-int:info :function :accessor-for place-function-name) ;; a workaround for the problem, encouraging the ;; inline expansion of the structure accessor, so ;; that the compiler can optimize its type test @@ -566,23 +489,8 @@ WORKAROUND: 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 - meaning is rather different, and it's unlikely that the user - has a good reason for doing DECLAIM not at top level, it would be - good to issue a STYLE-WARNING when this happens. A possible - fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level, - or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level. - [This is considered an IR1-interpreter-related bug because until - EVAL-WHEN is rewritten, which won't happen until after the IR1 - 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.] - 145: + a. 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 @@ -590,6 +498,18 @@ WORKAROUND: conformance problem, since seems hard to construct useful code where it matters.) + b. + * (defun foo (x) + (declare (type (double-float -0d0) x)) + (declare (optimize speed)) + (+ x (sqrt (log (random 1d0))))) + debugger invoked on condition of type SIMPLE-ERROR: + bad thing to be a type specifier: ((COMPLEX + (DOUBLE-FLOAT 0.0d0 + #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY)) + #C(0.0d0 #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY) + #C(0.0d0 #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY)) + 146: Floating point errors are reported poorly. E.g. on x86 OpenBSD with sbcl-0.7.1, @@ -602,42 +522,6 @@ WORKAROUND: 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. - - (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline - expand KID-FROB into %ZEEP. Having partially done it, it sees a call - of KIDIFY1, which already does not exist. So it gives up on - expansion, leaving garbage consisting of infinished blocks of the - partially converted function.) - - (due to reordering of the compiler this example is compiled - successfully by 0.7.14, but the bug probably remains) - (possibly exercised by bug 254 test case) - 162: (reported by Robert E. Brown 2002-04-16) When a function is called with too few arguments, causing the @@ -713,44 +597,6 @@ WORKAROUND: :FAST-MODE NIL) 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] - - In recent SBCL the following example also illustrates this bug: - (time (compile nil '(lambda () @@ -771,6 +617,15 @@ WORKAROUND: (print (incf start 22)) (print (incf start 26)))))) + This example could be solved with clever enough constraint + propagation or with SSA, but consider + + (let ((x 0)) + (loop (incf x 2))) + + The careful type of X is {2k} :-(. Is it really important to be + able to work with unions of many intervals? + 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 @@ -799,9 +654,8 @@ 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. - -201: "Incautious type inference from compound CONS types" - (reported by APD sbcl-devel 2002-09-17) +201: "Incautious type inference from compound types" + a. (reported by APD sbcl-devel 2002-09-17) (DEFUN FOO (X) (LET ((Y (CAR (THE (CONS INTEGER *) X)))) (SETF (CAR X) NIL) @@ -814,6 +668,17 @@ WORKAROUND: (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1" + b. + * (defun foo (x) + (declare (type (array * (4 4)) x)) + (let ((y x)) + (setq x (make-array '(4 4))) + (adjust-array y '(3 5)) + (= (array-dimension y 0) (eval `(array-dimension ,y 0))))) + FOO + * (foo (make-array '(4 4) :adjustable t)) + NIL + 205: "environment issues in cross compiler" (These bugs have no impact on user code, but should be fixed or documented.) @@ -954,22 +819,7 @@ WORKAROUND: Then (FOO #\1 *STANDARD-OUTPUT*) signals type error. (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not - produce invalid code, but type checking is not accurate. Similar - problems exist with VALUES-TYPE-INTERSECTION.) - -220: - Sbcl 0.7.9 fails to compile - - (multiple-value-call #'list - (the integer (helper)) - nil) - - Type check for INTEGER, the result of which serves as the first - argument of M-V-C, is inserted after evaluation of NIL. So arguments - of M-V-C are pushed in the wrong order. As a temporary workaround - type checking was disabled for M-V-Cs in 0.7.9.13. A better solution - would be to put the check between evaluation of arguments, but it - could be tricky to check result types of PROG1, IF etc. + produce invalid code, but type checking is not accurate.) 233: bugs in constraint propagation a. @@ -1009,17 +859,6 @@ WORKAROUND: (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 @@ -1093,14 +932,6 @@ WORKAROUND: 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". @@ -1113,42 +944,167 @@ WORKAROUND: does not cause a warning. (BTW: old SBCL issued a warning, but for a function, which was never called!) -253: "type checking is embedded THEs" - Compiler cannot perform type checking in - - (let () (list (the fixnum (the unsigned-byte (eval -1))))) - - (fixed in 0.8.0.34) - -254: (possibly bug 148 in a new guise) - In sbcl-0.8.0.52, COMPILE-FILE on - (cl:in-package :cl-user) - (declaim (optimize (safety 3) (debug 2) (speed 2) (space 1))) - (defstruct foo - (uhw2 nil :type (or package null))) - (macrolet ((defprojection (variant &key lexpr eexpr) - (let () - `(defmethod uu ((foo foo)) - (let ((uhw2 (foo.uhw2 bar))) - (let () - (u-flunt uhw2 - (baz (funcall ,lexpr south east 1))))))))) - (defprojection h - :lexpr (lambda (south east sched) - (flet ((bd (x) (bref x sched))) - (let ((avecname (gafp))) - (declare (type (vector t) avecname)) - (multiple-value-prog1 - (progn - (setf (avec.count avecname) (length rest)) - (setf (aref avecname 0) (bd (h south))) - (setf (aref avecname 1) (bd (h east))) - (stub avecname)) - (paip avecname))))) - :eexpr (lambda (south east)))) - fails with +256: + Compiler does not emit warnings for + + a. (lambda () (svref (make-array 8 :adjustable t) 1)) + + b. (lambda (x) + (list (let ((y (the real x))) + (unless (floatp y) (error "")) + y) + (integer-length x))) + + c. (lambda (x) + (declare (optimize (debug 0))) + (declare (type vector x)) + (list (fill-pointer x) + (svref x 1))) + +257: + Complex array type does not have corresponding type specifier. + + This is a problem because the compiler emits optimization notes when + you use a non-simple array, and without a type specifier for hairy + array types, there's no good way to tell it you're doing it + intentionally so that it should shut up and just compile the code. + + Another problem is confusing error message "asserted type ARRAY + conflicts with derived type (VALUES SIMPLE-VECTOR &OPTIONAL)" during + compiling (LAMBDA (V) (VALUES (SVREF V 0) (VECTOR-POP V))). + + The last problem is that when type assertions are converted to type + checks, types are represented with type specifiers, so we could lose + complex attribute. (Now this is probably not important, because + currently checks for complex arrays seem to be performed by + callees.) + +259: + (compile nil '(lambda () (aref (make-array 0) 0))) compiles without + warning. Analogous cases with the index and length being equal and + greater than 0 are warned for; the problem here seems to be that the + type required for an array reference of this type is (INTEGER 0 (0)) + which is canonicalized to NIL. + +260: + a. + (let* ((s (gensym)) + (t1 (specifier-type s))) + (eval `(defstruct ,s)) + (type= t1 (specifier-type s))) + => NIL, NIL + + (fixed in 0.8.1.24) + + b. The same for CSUBTYPEP. + +261: + * (let () (list (the (values &optional fixnum) (eval '(values))))) debugger invoked on condition of type TYPE-ERROR: - The value NIL is not of type SB-C::NODE. + The value NIL is not of type FIXNUM. + +262: "yet another bug in inline expansion of local functions" + Compiler fails on + + (defun foo (x y) + (declare (integer x y)) + (+ (block nil + (flet ((xyz (u) + (declare (integer u)) + (if (> (1+ (the unsigned-byte u)) 0) + (+ 1 u) + (return (+ 38 (cos (/ u 78))))))) + (declare (inline xyz)) + (return-from foo + (* (funcall (eval #'xyz) x) + (if (> x 30) + (funcall (if (> x 5) #'xyz #'identity) + (+ x 13)) + 38))))) + (sin (* x y)))) + + Urgh... It's time to write IR1-copier. + +265: + SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC; + attempting to use it leads to segmentation violations. This is + probably because of a bogus implementation of + os_restore_fp_control(). + +266: + David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix + behaviour of streams with element-type (SIGNED-BYTE 8). The patch + looks reasonable, if not obviously correct; however, it caused the + PPC/Linux port to segfault during warm-init while loading + src/pcl/std-class.fasl. A workaround patch was made, but it would + be nice to understand why the first patch caused problems, and to + fix the cause if possible. + +268: "wrong free declaration scope" + The following code must signal type error: + + (locally (declare (optimize (safety 3))) + (flet ((foo (x &optional (y (car x))) + (declare (optimize (safety 0))) + (list x y))) + (funcall (eval #'foo) 1))) + +269: + SCALE-FLOAT should accept any integer for its second argument. + +270: + In the following function constraint propagator optimizes nothing: + + (defun foo (x) + (declare (integer x)) + (declare (optimize speed)) + (typecase x + (fixnum "hala") + (fixnum "buba") + (bignum "hip") + (t "zuz"))) + +272: + All forms of GC hooks (including notifiers and finalisers) are currently + (since 0.8.0) broken for gencgc (i.e. x86) users + +273: + Compilation of the following two forms causes "X is unbound" error: + + (symbol-macrolet ((x pi)) + (macrolet ((foo (y) (+ x y))) + (declaim (inline bar)) + (defun bar (z) + (* z (foo 4))))) + (defun quux (z) + (bar z)) + + (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.) + +274: + CLHS says that type declaration of a symbol macro should not affect + its expansion, but in SBCL it does. + +275: + The following code (taken from CLOCC) takes a lot of time to compile: + + (defun foo (n) + (declare (type (integer 0 #.large-constant) n)) + (expt 1/10 n)) + + (fixed in 0.8.2.51, but a test case would be good) + +276: + (defmethod fee ((x fixnum)) + (setq x (/ x 2)) + x) + (fee 1) => type error + + (taken from CLOCC) + +277: + IGNORE/IGNORABLE declarations should be acceptable for symbol + macros. DEFUNCT CATEGORIES OF BUGS