X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=7f5faabe0095b7acc7c2844bafd38781ed05f356;hb=0d8cfa2891db9893099f9152bf9d26cbef1b7ed1;hp=4f58f70af239892d43b06ad1a2f2e6f2fbecb98e;hpb=8eccebd0e06f1ce6a9eed50ce5c0399a6c3216e6;p=sbcl.git diff --git a/BUGS b/BUGS index 4f58f70..7f5faab 100644 --- a/BUGS +++ b/BUGS @@ -584,11 +584,6 @@ WORKAROUND: GC, so that thereafter memory usage can never be reduced below that level. -96: - The TRACE facility can't be used on some kinds of functions. - (Basically, the breakpoint facility was incompletely implemented - in the X86 port of CMU CL, and hasn't been fixed in SBCL.) - 98: In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU CL), out-of-line structure slot setters are horribly inefficient @@ -972,18 +967,36 @@ WORKAROUND: (let ((x (1+ x))) (call-next-method))) Now (FOO 3) should return 3, but instead it returns 4. - -137: - (SB-DEBUG:BACKTRACE) output should start with something - including the name BACKTRACE, not (as in 0.pre7.88) - just "0: (\"hairy arg processor\" ...)". Until about - sbcl-0.pre7.109, the names in BACKTRACE were all screwed - up compared to the nice useful names in sbcl-0.6.13. - Around sbcl-0.pre7.109, they were mostly fixed by using - NAMED-LAMBDA to implement DEFUN. However, there are still - some screwups left, e.g. as of sbcl-0.pre7.109, there are - still some functions named "hairy arg processor" and - "SB-INT:&MORE processor". + +140: + (reported by Alexey Dejneka sbcl-devel 2002-01-03) + + SUBTYPEP does not work well with redefined classes: + --- + * (defclass a () ()) + # + * (defclass b () ()) + # + * (subtypep 'b 'a) + NIL + T + * (defclass b (a) ()) + # + * (subtypep 'b 'a) + T + T + * (defclass b () ()) + # + + ;;; And now... + * (subtypep 'b 'a) + T + T + + This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper + class upon redefinition. Unfortunately, doing so causes bug #176 to + appear. Pending further investication, one or other of these bugs + might be present at any given time. 141: Pretty-printing nested backquotes doesn't work right, as @@ -1112,13 +1125,6 @@ WORKAROUND: but it has happened in more complicated cases (which I haven't figured out how to reproduce). -156: - FUNCTION-LAMBDA-EXPRESSION doesn't work right in 0.7.0 or 0.7.2.9: - * (function-lambda-expression #'(lambda (x) x)) - debugger invoked on condition of type TYPE-ERROR: - The value NIL is not of type SB-C::DEBUG-SOURCE - (reported by Alexey Dejneka sbcl-devel 2002-04-12) - 157: Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument. @@ -1288,51 +1294,167 @@ WORKAROUND: (defclass c0 (b) ()) (make-instance 'c19) -177: - reported by Stig E Sandoe 8 Jun 2002 on sbcl-devel: - ;;; I am a bit unsure about SBCL's warnings with some of my code. - ;;; ASDF seems to die on warnings and SBCL seems to generate one - ;;; out of nothing. I've tried to turn it into an example - ;;; (that can be LOADed or COMPILEd to reproduce warnings): - (in-package :cl-user) - (defclass a () ()) - (defclass b () ()) - (defclass c (b) ()) - (defgeneric get-price (obj1 obj2)) - (defmethod get-price (obj1 obj2) - 0) - (defmethod get-price ((obj1 a) (obj2 b)) - 20) - (defmethod get-price ((obj1 a) (obj2 c)) - (* 3 (call-next-method))) - (print (get-price (make-instance 'a) (make-instance 'c))) - ;;; In the GET-PRICE where I call CALL-NEXT-METHOD, it starts to - ;;; generate real WARNINGS: - ;;; stig@palomba(9:02)[~] 690> sbcl - ;;; This is SBCL 0.7.4, an implementation of ANSI Common Lisp. - ;;; ... - ;;; * (load "call-next") - ;;; ; in: LAMBDA NIL - ;;; ; (CALL-NEXT-METHOD) - ;;; ; --> SB-PCL::CALL-NEXT-METHOD-BODY IF IF - ;;; ; --> SB-PCL::INVOKE-EFFECTIVE-METHOD-FUNCTION LOCALLY COND IF COND IF - ;;; PROGN - ;;; ; --> LET WHEN COND IF PROGN SETF LET* MULTIPLE-VALUE-BIND LET FUNCALL - ;;; ; --> SB-C::%FUNCALL BLOCK SETF SB-KERNEL:%SVSET SB-KERNEL:%ASET LET* - ;;; ; --> SB-KERNEL:HAIRY-DATA-VECTOR-SET MULTIPLE-VALUE-BIND - ;;; MULTIPLE-VALUE-CALL - ;;; ; --> FUNCTION - ;;; ; ==> - ;;; ; (SB-KERNEL:DATA-VECTOR-SET (TRULY-THE (SIMPLE-ARRAY T 1) ARRAY) - ;;; ; SB-INT:INDEX - ;;; ; SB-C::NEW-VALUE) - ;;; ; - ;;; ; caught WARNING: - ;;; ; Result is a A, not a NUMBER. - ;;; ... - ;;; ; compilation unit finished - ;;; ; caught 4 WARNING conditions + See also bug #140. +178: "AVER failure compiling confused THEs in FUNCALL" + In sbcl-0.7.4.24, compiling + (defun bug178 (x) + (funcall (the function (the standard-object x)))) + gives + failed AVER: + "(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))" + This variant compiles OK, though: + (defun bug178alternative (x) + (funcall (the nil x))) + +181: "bad type specifier drops compiler into debugger" + Compiling + (in-package :cl-user) + (defun bar (x) + (declare (type 0 x)) + (cons x x)) + signals + bad thing to be a type specifier: 0 + which seems fine, but also enters the debugger (instead of having + the compiler handle the error, convert it into a COMPILER-ERROR, and + continue compiling) which seems wrong. + +182: "SPARC/Linux floating point" + Evaluating (/ 1.0 0.0) at the prompt causes a Bus error and complete + death of the environment. Other floating point operations sometimes + return infinities when they should raise traps (e.g. the test case + for bug #146, (expt 2.0 12777)). + +183: "IEEE floating point issues" + Even where floating point handling is being dealt with relatively + well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the + accrued-exceptions and current-exceptions part of the fp control + word don't seem to bear much relation to reality. E.g. on + SPARC/SunOS: + * (/ 1.0 0.0) + + debugger invoked on condition of type DIVISION-BY-ZERO: + arithmetic error DIVISION-BY-ZERO signalled + 0] (sb-vm::get-floating-point-modes) + + (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO) + :ROUNDING-MODE :NEAREST + :CURRENT-EXCEPTIONS NIL + :ACCRUED-EXCEPTIONS (:INEXACT) + :FAST-MODE NIL) + 0] abort + * (sb-vm::get-floating-point-modes) + (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO) + :ROUNDING-MODE :NEAREST + :CURRENT-EXCEPTIONS (:INEXACT) + :ACCRUED-EXCEPTIONS (:INEXACT) + :FAST-MODE NIL) + +184: "division by zero becomes frozen into RATIO" + (reported by Wolfhard Buss on cmucl-imp 18 Jun 2002, fails on + sbcl-0.7.4.39 too) + * (/ 1 (/ 3 2) 0) + 1/0 + +185: "top-level forms at the REPL" + * (locally (defstruct foo (a 0 :type fixnum))) + gives an error: + ; caught ERROR: + ; (in macroexpansion of (SB-KERNEL::%DELAYED-GET-COMPILER-LAYOUT BAR)) + however, compiling and loading the same expression in a file works + as expected. + +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.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] DEFUNCT CATEGORIES OF BUGS IR1-#: