X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=109b0c9a584a672c8edd34c52a52e342b8c2fb6a;hb=2d4a0df3457bcd50916b33d374da592d8776db0a;hp=c8dd0f5f461f290ca78e5946c78c92afc4e6ddaa;hpb=010220a2273d434b4fa60546a8d10bdc25daf9e8;p=sbcl.git diff --git a/BUGS b/BUGS index c8dd0f5..109b0c9 100644 --- a/BUGS +++ b/BUGS @@ -257,17 +257,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 @@ -647,6 +636,7 @@ WORKAROUND: (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) @@ -722,63 +712,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 @@ -1180,17 +1113,43 @@ 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 +253: "type checking is embedded THEs" + Compiler cannot perform type checking in - (defun foo (x) - (list x)) - (defun bar (x) - (+ x (foo x))) + (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 + debugger invoked on condition of type TYPE-ERROR: + The value NIL is not of type SB-C::NODE. - (fixed in 0.8.0.27) DEFUNCT CATEGORIES OF BUGS IR1-#: