X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=109b0c9a584a672c8edd34c52a52e342b8c2fb6a;hb=2d4a0df3457bcd50916b33d374da592d8776db0a;hp=3389897784e44b1348a66768b8b1286f7a3f3ff7;hpb=ca379afc74fe525fd70035546d066de5f5ec874d;p=sbcl.git diff --git a/BUGS b/BUGS index 3389897..109b0c9 100644 --- a/BUGS +++ b/BUGS @@ -84,7 +84,9 @@ 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. + 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))) @@ -197,19 +199,6 @@ WORKAROUND: (Also, verify that the compiler handles declared function return types as assertions.) -41: - TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in - (DEFTYPE INDEXOID () '(INTEGER 0 1000)) - (DEFUN FOO (X) - (DECLARE (TYPE INDEXOID X)) - (THE (VALUES INDEXOID) - (VALUES X))) - where the implementation of the type check in function FOO - includes a full call to %TYPEP. There are also some fundamental problems - with the interpretation of VALUES types (inherited from CMU CL, and - from the ANSI CL standard) as discussed on the cmucl-imp@cons.org - mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000. - 42: The definitions of SIGCONTEXT-FLOAT-REGISTER and %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not @@ -258,24 +247,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. - 60: The debugger LIST-LOCATIONS command doesn't work properly. @@ -286,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 @@ -676,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) @@ -751,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 @@ -895,65 +799,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) @@ -969,14 +814,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.) @@ -1009,15 +846,6 @@ WORKAROUND: to redo MIX using a lookup into a 256-entry s-box containing 29-bit pseudorandom numbers? -208: "package confusion in PCL handling of structure slot handlers" - In sbcl-0.7.8 compiling and loading - (in-package :cl) - (defstruct foo (slot (error "missing")) :type list :read-only t) - (defmethod print-object ((foo foo) stream) (print nil stream)) - causes CERROR "attempting to modify a symbol in the COMMON-LISP - package: FOO-SLOT". (This is fairly bad code, but still it's hard - to see that it should cause symbols to be interned in the CL package.) - 211: "keywords processing" a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd number of keyword arguments. @@ -1129,12 +957,6 @@ WORKAROUND: produce invalid code, but type checking is not accurate. Similar problems exist with VALUES-TYPE-INTERSECTION.) -218: "VALUES type specifier semantics" - (THE (VALUES ...) ...) in safe code discards extra values. - - (defun test (x y) (the (values integer) (truncate x y))) - (test 10 4) => 2 - 220: Sbcl 0.7.9 fails to compile @@ -1149,9 +971,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. -229: - (subtypep 'function '(function)) => nil, t. - 233: bugs in constraint propagation a. (defun foo (x) @@ -1201,23 +1020,6 @@ WORKAROUND: Without (DECLARE (NOTINLINE MAPCAR)), Python cannot derive that Z is LIST. -236: "THE semantics is broken" - - (defun foo (a f) - (declare (optimize (speed 2) (safety 0))) - (+ 1d0 - (the double-float - (multiple-value-prog1 - (svref a 0) - (unless f (return-from foo 0)))))) - - (foo #(4) nil) => SEGV - - VOP selection thinks that in unsafe code result type assertions - should be valid immediately. (See also bug 233a.) - - The similar problem exists for TRULY-THE. - 237: "Environment arguments to type functions" a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE now have an optional environment @@ -1287,15 +1089,6 @@ WORKAROUND: ; caught STYLE-WARNING: ; The variable Y is defined but never used. -244: "optimizing away tests for &KEY args of type declared in DEFKNOWN" - (caught by clocc-ansi-test :EXCEPSIT-LEGACY-1050) - In sbcl-0.pre8.44, (OPEN "foo" :DIRECTION :INPUT :EXTERNAL-FORMAT 'FOO) - succeeds with no error (ignoring the bogus :EXTERNAL-FORMAT argument) - apparently because the test is optimized away. The problem doesn't - exist in sbcl-0.pre8.19. Deleting the (MEMBER :DEFAULT) declaration - for :EXTERNAL-FORMAT in DEFKNOWN OPEN (and LOAD) is a workaround for - the problem (and should be removed when the problem is fixed). - 245: bugs in disassembler a. On X86 an immediate operand for IMUL is printed incorrectly. b. On X86 operand size prefix is not recognized. @@ -1308,12 +1101,55 @@ WORKAROUND: (NTH-VALUE 1000 (VALUES-LIST (MAKE-LIST 1001))) takes several hours to compile. -247: "incomplete conversion of stack parameters in #-SB-THREAD code" - In 0.pre8.67/x86/nothreads, executing (ROOM) causes an error to - be signalled: - The variable SB-VM:CONTROL-STACK-END is unbound. - (When this is fixed, the ROOM entries in tests/smoke.impure.lisp - should be uncommented.) +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!) + +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 + debugger invoked on condition of type TYPE-ERROR: + The value NIL is not of type SB-C::NODE. + DEFUNCT CATEGORIES OF BUGS IR1-#: