X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=534f427fb98fac64556a0f0c5dd2fec2263c9026;hb=942e5de3f3e27e1cc6ae4aae69c040fa1dc7db00;hp=aa0675e984fb93940d639a4d6adb2dbbab4b6113;hpb=dbfe7e6c8b06e1b0b1ba35d9894fae13e6305602;p=sbcl.git diff --git a/BUGS b/BUGS index aa0675e..534f427 100644 --- a/BUGS +++ b/BUGS @@ -108,23 +108,6 @@ WORKAROUND: 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: @@ -207,13 +190,6 @@ 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: @@ -257,17 +233,6 @@ WORKAROUND: then requesting a BACKTRACE at the debugger prompt gives no information about where in the user program the problem occurred. -63: - Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15 - I am looking into this problem that showed up on the cmucl-help - list. It seems to me that the "implementation specific environment - hacking functions" found in pcl/walker.lisp are completely messed - up. The good thing is that they appear to be barely used within - PCL and the munged environment object is passed to cmucl only - in calls to macroexpand-1, which is probably why this case fails. - SBCL uses essentially the same code, so if the environment hacking - is screwed up, it affects us too. - 64: Using the pretty-printer from the command prompt gives funny results, apparently because the pretty-printer doesn't know @@ -392,7 +357,7 @@ WORKAROUND: 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 @@ -577,22 +542,6 @@ 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: ANSI allows types `(COMPLEX ,FOO) to use very hairy values for FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL @@ -722,63 +671,6 @@ WORKAROUND: :ACCRUED-EXCEPTIONS (:INEXACT) :FAST-MODE NIL) -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 @@ -1160,14 +1052,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". @@ -1180,22 +1064,8 @@ WORKAROUND: does not cause a warning. (BTW: old SBCL issued a warning, but for a function, which was never called!) -252: - (reported by Eric Marsden on sbcl-devel 2003-06-02) - Block-compiling (using the :block-compile argument to COMPILE-FILE) - causes an internal error on a simple file containing - - (defun foo (x) - (list x)) - (defun bar (x) - (+ x (foo x))) - - (fixed in 0.8.0.27) - -253: "type checking is embedded THEs" - Compiler cannot perform type checking in - - (let () (list (the fixnum (the unsigned-byte (eval -1))))) +255: + (fixed in 0.8.0.57) DEFUNCT CATEGORIES OF BUGS IR1-#: