X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=bba6c83e684dddc234652ac2f544d3ca677d68d4;hb=94ac5b7c3ff37850210b6fc9a7593cf1c5752993;hp=4f58f70af239892d43b06ad1a2f2e6f2fbecb98e;hpb=8eccebd0e06f1ce6a9eed50ce5c0399a6c3216e6;p=sbcl.git

diff --git a/BUGS b/BUGS
index 4f58f70..bba6c83 100644
--- a/BUGS
+++ b/BUGS
@@ -972,18 +972,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 () ())
+  #<STANDARD-CLASS A>
+  * (defclass b () ())
+  #<STANDARD-CLASS B>
+  * (subtypep 'b 'a)
+  NIL
+  T
+  * (defclass b (a) ())
+  #<STANDARD-CLASS B>
+  * (subtypep 'b 'a)
+  T
+  T
+  * (defclass b () ())
+  #<STANDARD-CLASS 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 
@@ -1288,51 +1306,61 @@ 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)
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#: