(I didn't have convenient access to the Internet for almost a week, so

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 9bec3d3..8ee4891 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -50,31 +50,33 @@ WORKAROUND:
   believers in ANSI compatibility and all, (1) there's no obvious
   simple way to do it (short of disabling all warnings for type
   mismatches everywhere), and (2) there's a good portable
   believers in ANSI compatibility and all, (1) there's no obvious
   simple way to do it (short of disabling all warnings for type
   mismatches everywhere), and (2) there's a good portable

-  workaround. ANSI justifies this specification by saying 
+  workaround, and (3) by their own reasoning, it looks as though
+  ANSI may have gotten it wrong. ANSI justifies this specification
+  by saying 

     The restriction against issuing a warning for type mismatches
     between a slot-initform and the corresponding slot's :TYPE
     option is necessary because a slot-initform must be specified
     in order to specify slot options; in some cases, no suitable
     default may exist.
     The restriction against issuing a warning for type mismatches
     between a slot-initform and the corresponding slot's :TYPE
     option is necessary because a slot-initform must be specified
     in order to specify slot options; in some cases, no suitable
     default may exist.

-  In SBCL, as in CMU CL (or, for that matter, any compiler which
-  really understands Common Lisp types) a suitable default does
-  exist, in all cases, because the compiler understands the concept
-  of functions which never return (i.e. has return type NIL, e.g.
-  ERROR). Thus, as a portable workaround, you can use a call to
-  some known-never-to-return function as the default. E.g.
+  However, in SBCL (as in CMU CL or, for that matter, any compiler
+  which really understands Common Lisp types) a suitable default
+  does exist, in all cases, because the compiler understands the
+  concept of functions which never return (i.e. has return type NIL).
+  Thus, as a portable workaround, you can use a call to some
+  known-never-to-return function as the default. E.g.

     (DEFSTRUCT FOO
       (BAR (ERROR "missing :BAR argument")
            :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
   or 
     (DEFSTRUCT FOO
       (BAR (ERROR "missing :BAR argument")
            :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
   or 

-    (DECLAIM (FTYPE () NIL) MISSING-ARG) 
+    (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG))

     (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
       (ERROR "missing required argument")) 
     (DEFSTRUCT FOO
       (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
       (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
       (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
     (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
       (ERROR "missing required argument")) 
     (DEFSTRUCT FOO
       (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
       (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
       (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))

-  Such code will compile without complaint and work correctly either
-  on SBCL or on a completely compliant Common Lisp system.
+  Such code should compile without complaint and work correctly either
+  on SBCL or on any other completely compliant Common Lisp system.

 
 6:
   bogus warnings about undefined functions for magic functions like
 
 6:
   bogus warnings about undefined functions for magic functions like

@@ -124,45 +126,9 @@ WORKAROUND:
   (Also, when this is fixed, we can enable the code in PROCLAIM which 
   checks for incompatible FTYPE redeclarations.)
 
   (Also, when this is fixed, we can enable the code in PROCLAIM which 
   checks for incompatible FTYPE redeclarations.)
 

-18:
-  from DTC on the CMU CL mailing list 25 Feb 2000:
-;;; Compiler fails when this file is compiled.
-;;;
-;;; Problem shows up in delete-block within ir1util.lisp. The assertion
-;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment)))
-;;; fails within bind node branch.
-;;;
-;;; Note that if c::*check-consistency* is enabled then an un-reached
-;;; entry is also reported.
-;;;
-(defun foo (val)
-  (declare (values nil))
-  nil)
-(defun bug (val)
-  (multiple-value-call
-      #'(lambda (res)
-          (block nil
-            (tagbody
-             loop
-               (when res
-                 (return nil))
-               (go loop))))
-    (foo val))
-  (catch 'ccc1
-    (throw 'ccc1
-      (block bbbb
-        (tagbody
-
-           (let ((ttt #'(lambda () (go cccc))))
-             (declare (special ttt))
-             (return-from bbbb nil))
-
-         cccc
-           (return-from bbbb nil))))))
-

 19:
   (I *think* this is a bug. It certainly seems like strange behavior. But
 19:
   (I *think* this is a bug. It certainly seems like strange behavior. But

-  the ANSI spec is scary, dark, and deep..)
+  the ANSI spec is scary, dark, and deep.. -- WHN)

     (FORMAT NIL  "~,1G" 1.4) => "1.    "
     (FORMAT NIL "~3,1G" 1.4) => "1.    "
 
     (FORMAT NIL  "~,1G" 1.4) => "1.    "
     (FORMAT NIL "~3,1G" 1.4) => "1.    "
 

@@ -171,6 +137,8 @@ WORKAROUND:
        (defclass ccc () ())
        (setf (find-class 'ccc1) (find-class 'ccc))
        (defmethod zut ((c ccc1)) 123)
        (defclass ccc () ())
        (setf (find-class 'ccc1) (find-class 'ccc))
        (defmethod zut ((c ccc1)) 123)

+  In sbcl-0.7.1.13, this gives an error, 
+       There is no class named CCC1.

   DTC's recommended workaround from the mailing list 3 Mar 2000:
        (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
 
   DTC's recommended workaround from the mailing list 3 Mar 2000:
        (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
 

@@ -189,24 +157,6 @@ WORKAROUND:
        Process inferior-lisp exited abnormally with code 1
   I haven't noticed a repeatable case of this yet.
 
        Process inferior-lisp exited abnormally with code 1
   I haven't noticed a repeatable case of this yet.
 

-29:
-  some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
-    (DEFUN BAR? (X)
-      (OR (NAR? X)
-          (BLOCK USED-BY-SOME-Y?
-            (FLET ((FROB (STK)
-                     (DOLIST (Y STK)
-                       (UNLESS (REJECTED? Y)
-                         (RETURN-FROM USED-BY-SOME-Y? T)))))
-              (DECLARE (INLINE FROB))
-              (FROB (RSTK X))
-              (FROB (MRSTK X)))
-            NIL)))
-  gives
-   error in function SB-KERNEL:ASSERT-ERROR:
-   The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
-  This is still present in sbcl-0.6.8.
-

 31:
   In some cases the compiler believes type declarations on array
   elements without checking them, e.g.
 31:
   In some cases the compiler believes type declarations on array
   elements without checking them, e.g.

@@ -270,11 +220,6 @@ WORKAROUND:
   (Also, verify that the compiler handles declared function
   return types as assertions.)
 
   (Also, verify that the compiler handles declared function
   return types as assertions.)
 

-38:
-  DEFMETHOD doesn't check the syntax of &REST argument lists properly,
-  accepting &REST even when it's not followed by an argument name:
-       (DEFMETHOD FOO ((X T) &REST) NIL)
-

 41:
   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in 
        (DEFTYPE INDEXOID () '(INTEGER 0 1000))
 41:
   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in 
        (DEFTYPE INDEXOID () '(INTEGER 0 1000))

@@ -312,21 +257,24 @@ WORKAROUND:
 45:
   a slew of floating-point-related errors reported by Peter Van Eynde
   on July 25, 2000:
 45:
   a slew of floating-point-related errors reported by Peter Van Eynde
   on July 25, 2000:

-       a: (fixed in sbcl-0.6.11.25)

        b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and 
           should probably be 1.4012985e-45. In SBCL,
           (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
           than LEAST-POSITIVE-SHORT-FLOAT. Similar problems 
           exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
           and LEAST-NEGATIVE-LONG-FLOAT.
        b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and 
           should probably be 1.4012985e-45. In SBCL,
           (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
           than LEAST-POSITIVE-SHORT-FLOAT. Similar problems 
           exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
           and LEAST-NEGATIVE-LONG-FLOAT.

-       c: Many expressions generate floating infinity:
+       c: Many expressions generate floating infinity on x86/Linux:

                (/ 1 0.0)
                (/ 1 0.0d0)
                (EXPT 10.0 1000)
                (EXPT 10.0d0 1000)
                (/ 1 0.0)
                (/ 1 0.0d0)
                (EXPT 10.0 1000)
                (EXPT 10.0d0 1000)

-          PVE's regression tests want them to raise errors. SBCL
-          generates the infinities instead, which may or may not be
-          conforming behavior.
+          PVE's regression tests want them to raise errors. sbcl-0.7.0.5
+          on x86/Linux generates the infinities instead. That might or
+          might not be conforming behavior, but it's also inconsistent,
+           which is almost certainly wrong. (Inconsistency: (/ 1 0.0)
+          should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0)
+          generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0)
+          signals an error.

        d: (in section12.erg) various forms a la 
                (FLOAT 1 DOUBLE-FLOAT-EPSILON)
           don't give the right behavior.
        d: (in section12.erg) various forms a la 
                (FLOAT 1 DOUBLE-FLOAT-EPSILON)
           don't give the right behavior.

@@ -388,11 +336,7 @@ WORKAROUND:
        d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
           blows up at the level of SPECIFIER-TYPE with
           "Lower bound (0) is greater than upper bound (0)." Probably
        d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
           blows up at the level of SPECIFIER-TYPE with
           "Lower bound (0) is greater than upper bound (0)." Probably

-          SPECIFIER-TYPE should return NIL instead.
-       e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with
-          "Component type for Complex is not numeric: (EQL 0)."
-          This might be easy to fix; the type system already knows
-          that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
+          SPECIFIER-TYPE should return the NIL type instead.

        g: The type system isn't all that smart about relationships
           between hairy types, as shown in the type.erg test results,
           e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
        g: The type system isn't all that smart about relationships
           between hairy types, as shown in the type.erg test results,
           e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.

@@ -423,13 +367,6 @@ WORKAROUND:
   The implementation of #'+ returns its single argument without
   type checking, e.g. (+ "illegal") => "illegal".
 
   The implementation of #'+ returns its single argument without
   type checking, e.g. (+ "illegal") => "illegal".
 

-56:
-  Attempting to use COMPILE on something defined by DEFMACRO fails:
-       (DEFMACRO FOO (X) (CONS X X))
-       (COMPILE 'FOO)
-Error in function C::GET-LAMBDA-TO-COMPILE:
-   #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
-

 58:
   (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
   Note: I looked into fixing this in 0.6.11.15, but gave up. The
 58:
   (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
   Note: I looked into fixing this in 0.6.11.15, but gave up. The

@@ -690,8 +627,8 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
     (assert (not (eq type1 *wild-type*)))
   in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
   in a type context should probably be translated to T, and so it's
     (assert (not (eq type1 *wild-type*)))
   in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
   in a type context should probably be translated to T, and so it's

-  probably to ask whether it's equal to the T type and then (using the
-  EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
+  probably wrong to ask whether it's equal to the T type and then (using
+  the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.

   (I haven't tried to investigate this bug enough to guess whether
   there might be any user-level symptoms.)
 
   (I haven't tried to investigate this bug enough to guess whether
   there might be any user-level symptoms.)
 

@@ -715,25 +652,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   clear what's the best fix. (See the "bug in type handling" discussion
   on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
 
   clear what's the best fix. (See the "bug in type handling" discussion
   on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
 

-93:
-  In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
-  src/cold/shared.lisp doesn't correctly translate the
-  interpreted function
-    (defun in-host-compilation-mode (fn)
-      (let ((*features* (cons :sb-xc-host *features*))
-            ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in
-            ;; base-target-features.lisp-expr:
-            (*shebang-features* (set-difference *shebang-features*
-                                                '(:sb-propagate-float-type
-                                                  :sb-propagate-fun-type))))
-        (with-additional-nickname ("SB-XC" "SB!XC")
-          (funcall fn))))
-  No error is reported by the compiler, but when the function is executed,
-  it causes an error
-    TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
-      (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
-       :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
-

 94a: 
   Inconsistencies between derived and declared VALUES return types for
   DEFUN aren't checked very well. E.g. the logic which successfully
 94a: 
   Inconsistencies between derived and declared VALUES return types for
   DEFUN aren't checked very well. E.g. the logic which successfully

@@ -808,18 +726,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
       ;; no problem, can just use the ordinary expansion
       `(function (setf ,place-function-name))))
 
       ;; no problem, can just use the ordinary expansion
       `(function (setf ,place-function-name))))
 

-99:
-  DESCRIBE interacts poorly with *PRINT-CIRCLE*, e.g. the output from 
-    (let ((*print-circle* t)) (describe (make-hash-table)))
-  is weird,
-    #<HASH-TABLE :TEST EQL :COUNT 0 {90BBFC5}> is an . (EQL)
-    Its SIZE is 16.
-    Its REHASH-SIZE is 1.5. Its REHASH-THRESHOLD is . (1.0)
-    It holds 0 key/value pairs.
-  where the ". (EQL)" and ". (1.0)" substrings are screwups.
-  (This is likely a pretty-printer problem which happens to
-  be exercised by DESCRIBE, not actually a DESCRIBE problem.)
-

 100:
   There's apparently a bug in CEILING optimization which caused 
   Douglas Crosher to patch the CMU CL version. Martin Atzmueller
 100:
   There's apparently a bug in CEILING optimization which caused 
   Douglas Crosher to patch the CMU CL version. Martin Atzmueller

@@ -850,14 +756,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
          /usr/stuff/sbcl/src/code/host-alieneval.lisp
            Created: Monday, March 12, 2001 07:47:43 AM CST
 
          /usr/stuff/sbcl/src/code/host-alieneval.lisp
            Created: Monday, March 12, 2001 07:47:43 AM CST
 

-105:
-  (DESCRIBE 'STREAM-READ-BYTE)
-
-106:
-  (reported by Eric Marsden on cmucl-imp 2001-06-15)
-  (and APD pointed out on sbcl-devel 2001-12-29 that it's the same
-  as bug 50e)
-

 108:
   (TIME (ROOM T)) reports more than 200 Mbytes consed even for
   a clean, just-started SBCL system. And it seems to be right:
 108:
   (TIME (ROOM T)) reports more than 200 Mbytes consed even for
   a clean, just-started SBCL system. And it seems to be right:

@@ -902,44 +800,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   type declarations are supposed to be treated as assertions unless
   SAFETY 0, so we should be getting a TYPE-ERROR.
 
   type declarations are supposed to be treated as assertions unless
   SAFETY 0, so we should be getting a TYPE-ERROR.
 

-111:
-  reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
-  collection:
-    (in-package :cl-user)
-    ;;; Produces an assertion failures when compiled.
-    (defun foo (z)
-      (declare (type (or (function (t) t) null) z))
-      (let ((z (or z #'identity)))
-        (declare (type (function (t) t) z))
-        (funcall z 1)))
-  The error in sbcl-0.6.12.42 is
-    internal error, failed AVER:
-      "(COMMON-LISP:NOT (COMMON-LISP:EQ SB!C::CHECK COMMON-LISP:T))"
-
-112:
-  reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs
-  collection; apparently originally reported by Bruno Haible
-    (in-package :cl-user)
-    ;;; From: Bruno Haible
-    ;;; Subject: scope of SPECIAL declarations
-    ;;; It seems CMUCL has a bug relating to the scope of SPECIAL
-    ;;; declarations.  I observe this with "CMU Common Lisp 18a x86-linux
-    ;;; 1.4.0 cvs".
-    (let ((x 0))
-      (declare (special x))
-      (let ((x 1))
-        (let ((y x))
-          (declare (special x)) y)))
-    ;;; Gives: 0 (this should return 1 according to CLHS)
-    (let ((x 0))
-      (declare (special x))
-      (let ((x 1))
-        (let ((y x) (x 5))
-          (declare (special x)) y)))
-    ;;; Gives: 1 (correct).
-  The reported results match what we get from the interpreter
-  in sbcl-0.6.12.42.
-

 113:
   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
   collection:
 113:
   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
   collection:

@@ -1135,14 +995,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   structure classes related by inheritance. As of 0.7.0, SBCL still 
   doesn't follow it.
 
   structure classes related by inheritance. As of 0.7.0, SBCL still 
   doesn't follow it.
 

-128:
-  READ-SEQUENCE doesn't work for Gray streams. (reported by Nathan
-  Froyd sbcl-devel 2001-10-15) As per subsequent discussion on the 
-  list, the Gray streams proposal doesn't mention READ-SEQUENCE and
-  WRITE-SEQUENCE because it predates them, generalizing it to 
-  cover them is an obvious extension, ACL does it, and there's a 
-  patch for for CMU CL which does it too.
-

 129:
   insufficient syntax checking in MACROLET:
    (defun foo (x)
 129:
   insufficient syntax checking in MACROLET:
    (defun foo (x)

@@ -1150,25 +1002,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
        (bar x)))
   shouldn't compile without error (because of the extra DEFMACRO symbol).
 
        (bar x)))
   shouldn't compile without error (because of the extra DEFMACRO symbol).
 

-130:
-  reported by Alexey Dejneka on sbcl-devel 2001-11-03
-   (defun x (x)
-     "Return X if X is a non-negative integer."
-     (let ((step (lambda (%funcall)
-                   (lambda (n)
-                     (cond ((= n 0) 0)
-                           (t (1+ (funcall %funcall (1- n)))))))))
-       (funcall
-        ((lambda (a)
-           (funcall step (lambda (n)
-                           (funcall (funcall a a) n))))
-         (lambda (a)
-           (funcall step (lambda (n)
-                           (funcall (funcall a a) n)))))
-        x)))
-  This function returns its argument. But after removing percents it
-  does not work: "Result of (1- n) is not a function".
-

 131:
   As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably 
   the CL:COMPILE function (which is based on the same %COMPILE 
 131:
   As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably 
   the CL:COMPILE function (which is based on the same %COMPILE 

@@ -1242,31 +1075,6 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   internal compiler error. (This error occurs in sbcl-0.6.13 and in
   0.pre7.86.flaky7.14.)
 
   internal compiler error. (This error occurs in sbcl-0.6.13 and in
   0.pre7.86.flaky7.14.)
 

-133:
-  Trying to compile something like 
-    (sb!alien:def-alien-routine "breakpoint_remove" sb!c-call:void
-      (code-obj sb!c-call:unsigned-long)
-      (pc-offset sb!c-call:int)
-      (old-inst sb!c-call:unsigned-long))
-  in SBCL-0.pre7.86.flaky7.22 after warm init fails with an error
-    cannot use values types here
-  probably because the SB-C-CALL:VOID type gets translated to (VALUES).
-  It should be valid to use VOID for a function return type, so perhaps
-  instead of calling SPECIFIER-TYPE (which excludes all VALUES types
-  automatically) we should call VALUES-SPECIFIER-TYPE and handle VALUES
-  types manually, allowing the special case (VALUES) but still excluding
-  all more-complex VALUES types.
-
-134:
-  (reported by Alexey Dejneka sbcl-devel 2001-12-07)
-    (let ((s '((1 2 3))))
-      (eval (eval ``(vector ,@',@s))))
-      
-    should return #(1 2 3), instead of this it causes a reader error.
-      
-    Interior call of BACKQUOTIFY erroneously optimizes ,@': it immediately
-    splices the temporal representation of ,@S.
-    

 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 
 135:
   Ideally, uninterning a symbol would allow it, and its associated
   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 

@@ -1289,102 +1097,79 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
 137:
   (SB-DEBUG:BACKTRACE) output should start with something
   including the name BACKTRACE, not (as in 0.pre7.88)
 137:
   (SB-DEBUG:BACKTRACE) output should start with something
   including the name BACKTRACE, not (as in 0.pre7.88)

-  just "0: (\"hairy arg processor\" ...)". In general
-  the names in BACKTRACE are all screwed up compared to
-  the nice useful names in 0.6.13.
-
-  Note for those who observe that this is an annoying
-  bug and doesn't belong in a release: See the "note for the 
-  ambitious", below.
-
-  Note for the ambitious: This is an important bug and I'd
-  really like to fix it and spent many hours on it. The 
-  obvious ways to fix it are hard, because the underlying
-  infrastructure seems to be rather broken.
-  * There are two mostly-separate systems for storing names,
-    the in-the-function-object system used by e.g.
-    CL:FUNCTION-LAMBDA-EXPRESSION and the
-    in-the-DEBUG-FUN-object system used by e.g. BACKTRACE.
-    The code as of sbcl-0.pre7.94 is smart enough to set
-    up the first value, but not the second (because I naively
-    assumed that one mechanism is enough, and didn't proof
-    read the entire system to see whether there might be
-    another mechanism?! argh...)
-  * The systems are not quite separate, but instead weirdly and
-     fragilely coupled by the FUN-DEBUG-FUN algorithm.
-  * If you try to refactor this dain bramage away, reducing
-    things to a single system -- I tried to add a
-    %SIMPLE-FUN-DEBUG-FUN slot, planning eventually to get
-    rid of the old %SIMPLE-FUN-NAME slot in favor of indirection
-    through the new slot -- you get torpedoed by the fragility
-    of the SIMPLE-FUN primitive object. Just adding the
-    new slot, without making any other changes in the system,
-    is enough to make the system fail with what look like
-    memory corruption problems in warm init.
-  But please do fix some or all of the problem, I'm tired
-  of messing with it. -- WHN 2001-12-22
-
-138:
-  a cross-compiler bug in sbcl-0.pre7.107
-
-  $ cat > /tmp/bug139.lisp << EOF
-  (in-package "SB!KERNEL")
-  (defun f-c-l (name parent-types)
-    (let* ((cpl (mapcar (lambda (x) 
-                          (condition-class-cpl x))
-                        parent-types))
-           (new-inherits
-             (concatenate 'simple-vector
-                          (layout-inherits cond-layout))))
-      (if (not (mismatch (layout-inherits olayout) new-inherits))
-          olayout
-          (make-layout))))
-  EOF
-  $ sbcl --core output/after-xc.core
-  ...
-  * (target-compile-file "/tmp/bug139.lisp")
-  ...
-  internal error, failed AVER:
-    "(COMMON-LISP:MEMBER SB!C::FUN (SB!C::COMPONENT-LAMBDAS SB!C:COMPONENT))"
-
-  It seems as though this xc bug is likely to correspond to a bug in the
-  ordinary compiler, but I haven't yet found a test case which causes
-  this problem in the ordinary compiler.
-
-  related weirdness: Using #'(LAMBDA (X) ...) instead of (LAMBDA (X) ...)
-  makes the assertion failure go away.
-
-139:
-  In sbcl-0.pre7.107, (DIRECTORY "*.*") is broken, as reported by 
-  Nathan Froyd sbcl-devel 2001-12-28.
-
-  Christophe Rhodes suggested (sbcl-devel 2001-12-30) converting
-  the MERGED-PATHNAME expression in DEFUN DIRECTORY to
-        (merged-pathname (merge-pathnames pathname
-                                         *default-pathname-defaults*))
-  This looks right, and fixes this bug, but it interacts with the NODES
-  logic in %ENUMERATE-PATHNAMES to create a new bug, so that
-  (DIRECTORY "../**/*.*") no longer shows files in the current working
-  directory. Probably %ENUMERATE-PATHNAMES (or related logic like
-  %ENUMERATE-MATCHES) needs to be patched as well.
-
-  Note: The MERGED-PATHNAME change changes behavior incompatibly,
-  making e.g. (DIRECTORY "*") no longer equivalent to (DIRECTORY "*.*"),
-  so deserves a NEWS entry. E.g.
-* minor incompatible change (part of a bug fix by Christophe Rhodes
-  to DIRECTORY behavior): DIRECTORY no longer implicitly promotes
-  NIL slots of its pathname argument to :WILD, and in particular
-  asking for the contents of a directory, which you used to be able
-  to do without explicit wildcards, e.g. (DIRECTORY "/tmp/"), 
-  now needs explicit wildcards, e.g. (DIRECTORY "/tmp/*.*").
-
-
-KNOWN BUGS RELATED TO THE IR1 INTERPRETER
-
-(Now that the IR1 interpreter has gone away, these should be 
-relatively straightforward to fix.)
-
-IR1-4:
+  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
+
+141: 
+  Pretty-printing nested backquotes doesn't work right, as 
+  reported by Alexey Dejneka sbcl-devel 2002-01-13:
+  * '``(FOO ,@',@S)
+  ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
+  * (lisp-implementation-version)
+  "0.pre7.129"
+
+142:
+  (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16)
+  %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte
+  of the naturalized string. We could probably port the patches
+  from the cmucl-imp mailing list.
+
+143:
+  (reported by Jesse Bouwman 2001-10-24 through the unfortunately
+  prominent SourceForge web/db bug tracking system, which is 
+  unfortunately not a reliable way to get a timely response from
+  the SBCL maintainers)
+      In the course of trying to build a test case for an 
+    application error, I encountered this behavior: 
+      If you start up sbcl, and then lay on CTRL-C for a 
+    minute or two, the lisp process will eventually say: 
+         %PRIMITIVE HALT called; the party is over. 
+    and throw you into the monitor. If I start up lisp, 
+    attach to the process with strace, and then do the same 
+    (abusive) thing, I get instead: 
+         access failure in heap page not marked as write-protected 
+    and the monitor again. I don't know enough to have the 
+    faintest idea of what is going on here. 
+      This is with sbcl 6.12, uname -a reports: 
+         Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown 
+  I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141
+  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
   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

@@ -1398,6 +1183,111 @@ IR1-4:
   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.]
 
   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.]
 

-IR1-6:
-  (another wishlist thing..) Reimplement DEFMACRO to be basically
-  like DEFMACRO-MUNDANELY, just using EVAL-WHEN.
+145:
+  ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
+  FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
+  COMPLEX implementation didn't deal with this, and hasn't been
+  upgraded to do so. (This doesn't seem to be a high priority
+  conformance problem, since seems hard to construct useful code
+  where it matters.)
+
+146:
+  Floating point errors are reported poorly. E.g. on x86 OpenBSD
+  with sbcl-0.7.1, 
+       * (expt 2.0 12777)
+       debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
+         An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
+       No traps are enabled? How can this be?
+  It should be possible to be much more specific (overflow, division
+  by zero, etc.) and of course the "How can this be?" should be fixable.
+
+147:
+  (reported by Alexey Dejneka sbcl-devel 2002-01-28)
+  Compiling a file containing
+    (deftype digit () '(member #\1))
+    (defun parse-num (string ind)
+      (flet ((digs ()
+               (let (old-index)
+                 (if (and (< ind ind)
+                          (typep (char string ind) 'digit))
+                     nil))))))
+  in sbcl-0.7.1 causes the compiler to fail with
+    internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
+  This problem seems to have been introduced by the sbcl-0.pre7.* compiler
+  changes, since 0.pre7.73 and 0.6.13 don't suffer from it. A related
+  test case is
+    (defun parse-num (index)
+      (let (num x)
+        (flet ((digs ()
+                 (setq num index))
+               (z ()
+                 (let ()
+                   (setq x nil))))
+          (when (and (digs) (digs)) x))))
+  In sbcl-0.7.1, this second test case failed with the same
+    internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
+  After the APD patches in sbcl-0.7.1.2 (new consistency check in
+  TARGET-IF-DESIRABLE, plus a fix in meta-vmdef.lisp to keep the
+  new consistency check from failing routinely) this second test case
+  failed in FIND-IN-PHYSENV instead. Fixes in sbcl-0.7.1.3 (not
+  closing over unreferenced variables) made this second test case
+  compile without error, but the original test case still fails.
+ 
+  Another way to get rid of the DEFTYPE without changing the symptom
+  of the bug is
+    (defvar *ch*)
+    (defun parse-num (string ind)
+      (flet ((digs ()
+               (let ()
+                 (if (and (< ind ind)
+                         (sb-int:memq *ch* '(#\1)))
+                     nil))))))
+  In sbcl-0.7.1.3, this fails with
+    internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
+  The problem occurs while the inline expansion of MEMQ,
+  #<LAMBDA :%DEBUG-NAME "varargs entry point for SB-C::.ANONYMOUS.">
+  is being LET-converted after having its second REF deleted, leaving
+  it with only one entry in LEAF-REFS.
+  
+148:
+  In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
+    (in-package :cl-user)
+    (defvar *thing*)
+    (defvar *zoom*)
+    (defstruct foo bar bletch)
+    (defun %zeep ()
+      (labels ((kidify1 (kid)
+                )
+               (kid-frob (kid)
+                 (if *thing*
+                    (setf sweptm
+                          (m+ (frobnicate kid)
+                                    sweptm))
+                   (kidify1 kid))))
+      (declare (inline kid-frob))
+      (map nil
+          #'kid-frob
+          (the simple-vector (foo-bar perd)))))
+  fails with
+    debugger invoked on condition of type TYPE-ERROR:
+      The value NIL is not of type SB-C::NODE.
+  The location of this failure has moved around as various related
+  issues were cleaned up. As of sbcl-0.7.1.9, it occurs in 
+  NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
+
+149:
+  (reported by Stig E Sandoe sbcl-devel 2002-02-02)
+  In sbcl-0.7.1.13, compiling a DEFCLASS FOO form isn't enough to make
+  the class known to the compiler for other forms compiled in the same
+  file, so bogus warnings "undefined type: FOO" are generated, e.g.
+  when compiling 
+    (in-package :cl-user)
+    (defclass foo () ())
+    (defun bar (x)
+      (typep x 'foo))
+
+DEFUNCT CATEGORIES OF BUGS
+  IR1-#:
+    These numbers were used for bugs related to the old IR1
+    interpreter. The # values reached 6 before the category
+    was closed down.
\ No newline at end of file