0.8.21.50:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 08a6dc8..bf2c746 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -84,34 +84,12 @@ WORKAROUND:
 
   d: (fixed in 0.8.1.5)
 
 
   d: (fixed in 0.8.1.5)
 

-7:
-  The "compiling top-level form:" output ought to be condensed.
-  Perhaps any number of such consecutive lines ought to turn into a
-  single "compiling top-level forms:" line.
-
-19:
-  (I *think* this is a bug. It certainly seems like strange behavior. But
-  the ANSI spec is scary, dark, and deep.. -- WHN)
-    (FORMAT NIL  "~,1G" 1.4) => "1.    "
-    (FORMAT NIL "~3,1G" 1.4) => "1.    "
-

 27:
   Sometimes (SB-EXT:QUIT) fails with 
        Argh! maximum interrupt nesting depth (4096) exceeded, exiting
        Process inferior-lisp exited abnormally with code 1
   I haven't noticed a repeatable case of this yet.
 
 27:
   Sometimes (SB-EXT:QUIT) fails with 
        Argh! maximum interrupt nesting depth (4096) exceeded, exiting
        Process inferior-lisp exited abnormally with code 1
   I haven't noticed a repeatable case of this yet.
 

-32:
-  The printer doesn't report closures very well. This is true in 
-  CMU CL 18b as well:
-    (defstruct foo bar)
-    (print #'foo-bar)
-  gives
-    #<FUNCTION "CLOSURE" {406974D5}>
-  It would be nice to make closures have a settable name slot,
-  and make things like DEFSTRUCT and FLET, which create closures,
-  set helpful values into this slot.
-

 33:
   And as long as we're wishing, it would be awfully nice if INSPECT could
   also report on closures, telling about the values of the bound variables.
 33:
   And as long as we're wishing, it would be awfully nice if INSPECT could
   also report on closures, telling about the values of the bound variables.

@@ -157,10 +135,6 @@ WORKAROUND:
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 
   so they could be supported after all. Very likely 
   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 

-60:
-  The debugger LIST-LOCATIONS command doesn't work properly.
-  (How should it work properly?)
-

 61:
   Compiling and loading
     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
 61:
   Compiling and loading
     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))

@@ -611,18 +585,6 @@ WORKAROUND:
 211: "keywords processing"
   a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
      number of keyword arguments.
 211: "keywords processing"
   a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
      number of keyword arguments.

-  e. Compiling
-
-      (flet ((foo (&key y) (list y)))
-        (list (foo :y 1 :y 2)))
-
-     issues confusing message
-
-       ; in: LAMBDA NIL
-       ;     (FOO :Y 1 :Y 2)
-       ;
-       ; caught STYLE-WARNING:
-       ;   The variable #:G15 is defined but never used.

 
 212: "Sequence functions and circular arguments"
   COERCE, MERGE and CONCATENATE go into an infinite loop when given
 
 212: "Sequence functions and circular arguments"
   COERCE, MERGE and CONCATENATE go into an infinite loop when given

@@ -913,6 +875,14 @@ WORKAROUND:
 
   (fixed in 0.8.2.51, but a test case would be good)
 
 
   (fixed in 0.8.2.51, but a test case would be good)
 

+276:
+  b. The same as in a., but using MULTIPLE-VALUE-SETQ instead of SETQ.
+  c. (defvar *faa*)
+     (defmethod faa ((*faa* double-float))
+           (set '*faa* (when (< *faa* 0) (- *faa*)))
+           (1+ *faa*))
+     (faa 1d0) => type error
+

 278:
   a.
     (defun foo ()
 278:
   a.
     (defun foo ()

@@ -1091,17 +1061,6 @@ WORKAROUND:
 
   The problem is that both EVALs sequentially write to the same LVAR.
 
 
   The problem is that both EVALs sequentially write to the same LVAR.
 

-305:
-  (Reported by Dave Roberts.)
-  Local INLINE/NOTINLINE declaration removes local FTYPE declaration:
-
-    (defun quux (x)
-      (declare (ftype (function () (integer 0 10)) fee)
-               (inline fee))
-      (1+ (fee)))
-
-  uses generic arithmetic with INLINE and fixnum without.
-

 306: "Imprecise unions of array types"
   a.(defun foo (x)
       (declare (optimize speed)
 306: "Imprecise unions of array types"
   a.(defun foo (x)
       (declare (optimize speed)

@@ -1152,16 +1111,6 @@ WORKAROUND:
     Expected: (2 6 15 38)
     Got:      ERROR
 
     Expected: (2 6 15 38)
     Got:      ERROR
 

-317: "FORMAT of floating point numbers"
-  reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
-  test suite.
-    (format nil "~1F" 10) => "0." ; "10." expected
-    (format nil "~0F" 10) => "0." ; "10." expected
-    (format nil "~2F" 1234567.1) => "1000000." ; "1234567." expected
-  it would be nice if whatever fixed this also untangled the two
-  competing implementations of floating point printing (Steele and
-  White, and Burger and Dybvig) present in src/code/print.lisp
-

 318: "stack overflow in compiler warning with redefined class"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite.
 318: "stack overflow in compiler warning with redefined class"
   reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
   test suite.

@@ -1551,6 +1500,10 @@ WORKAROUND:
  (used on non-x86 platforms) being a more complete solution then what
  is done on x86.
 
  (used on non-x86 platforms) being a more complete solution then what
  is done on x86.
 

+ On x86/linux large portions of tests/debug.impure.lisp have been commented
+ out as failures. The probable culprit for these problems is in x86-call-context
+ (things work fine on x86/freebsd).
+

  More generally, the debugger internals suffer from excessive x86/non-x86
  conditionalization and OAOOMization: refactoring the common parts would
  be good.
  More generally, the debugger internals suffer from excessive x86/non-x86
  conditionalization and OAOOMization: refactoring the common parts would
  be good.

@@ -1563,6 +1516,13 @@ WORKAROUND:
  Has the XEP for TEST in the backtrace, not the TEST frame itself.
  (sparc and x86 at least)
 
  Has the XEP for TEST in the backtrace, not the TEST frame itself.
  (sparc and x86 at least)
 

+ Since SBCL 0.8.20.1 this is hidden unless *SHOW-ENTRY-POINT-DETAILS*
+ is true (instead there appear two TEST frames at least on ppc). The
+ underlying cause seems to be that SB-C::TAIL-ANNOTATE will not merge
+ the tail-call for the XEP, since Python has by that time proved that
+ the function can never return; same happens if the function holds an
+ unconditional call to ERROR.
+

 355: change-class of generic-function
     (reported by Bruno Haible)
   The MOP doesn't support change-class on a generic-function. However, SBCL
 355: change-class of generic-function
     (reported by Bruno Haible)
   The MOP doesn't support change-class on a generic-function. However, SBCL

@@ -2047,3 +2007,74 @@ WORKAROUND:
   point control word state and then returning the relevant float
   (most-positive-short-float or short-float-infinity) or signalling an
   error immediately would seem to make more sense.
   point control word state and then returning the relevant float
   (most-positive-short-float or short-float-infinity) or signalling an
   error immediately would seem to make more sense.

+
+372: floating-point overflow not signalled on ppc/darwin
+ The following assertions in float.pure.lisp fail on ppc/darwin 
+ (Mac OS X version 10.3.7):
+   (assert (raises-error? (scale-float 1.0 most-positive-fixnum)
+                         floating-point-overflow))
+   (assert (raises-error? (scale-float 1.0d0 (1+ most-positive-fixnum))
+                          floating-point-overflow)))
+ as the SCALE-FLOAT just returns 
+ #.SB-EXT:SINGLE/DOUBLE-FLOAT-POSITIVE-INFINITY. These tests have been
+ disabled on Darwin for now.
+
+374: BIT-AND problem on ppc/darwin:
+  The BIT-AND test in bit-vector.impure-cload.lisp results in
+    fatal error encountered in SBCL pid 8356:
+    GC invariant lost, file "gc-common.c", line 605
+  on ppc/darwin. Test disabled for the duration.
+
+375: MISC.555
+    (compile nil '(lambda (p1)
+                   (declare (optimize (speed 1) (safety 2) (debug 2) (space 0))
+                            (type keyword p1))
+                   (keywordp p1)))
+
+  fails on hairy type check in IR2.
+
+  1. KEYWORDP is MAYBE-INLINE expanded (before TYPEP-like
+     transformation could eliminate it).
+
+  2. From the only call of KEYWORDP the type of its argument is
+     derived to be KEYWORD.
+
+  2. Type check for P1 is generated; it uses KEYWORDP to perform the
+     check, and so references the local function; from the KEYWORDP
+     argument type new CAST to KEYWORD is generated. The compiler
+     loops forever.
+
+377: Memory fault error reporting
+  On those architectures where :C-STACK-IS-CONTROL-STACK is in
+  *FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
+  so we cannot handle the signal directly (as in interrupt_handle_now())
+  in the case when the signal comes from some external agent (the user
+  using kill(1), or a fault in some foreign code, for instance).  As
+  of sbcl-0.8.20.20, this is fixed by calling
+  arrange_return_to_lisp_function() to a new error-signalling
+  function, but as a result the error reporting is poor: we cannot
+  even tell the user at which address the fault occurred.  We should
+  arrange such that arguments can be passed to the function called from
+  arrange_return_to_lisp_function(), but this looked hard to do in
+  general without suffering from memory leaks.
+
+378: floating-point exceptions not signalled on x86-64
+  Floating point traps are currently not enabled on the x86-64 port.
+  This is true for at least overflow detection (as tested in
+  float.pure.lisp) and divide-by-zero.
+
+379: TRACE :ENCAPSULATE NIL broken on ppc/darwin
+  See commented-out test-case in debug.impure.lisp.
+
+380: Accessor redefinition fails because of old accessor name
+  When redefining an accessor, SB-PCL::FIX-SLOT-ACCESSORS may try to
+  find the generic function named by the old accessor name using
+  ENSURE-GENERIC-FUNCTION and then remove the old accessor's method in
+  the GF. If the old name does not name a function, or if the old name
+  does not name a generic function, no attempt to find the GF or remove
+  any methods is made.
+
+  However, if an unrelated GF with an incompatible lambda list exists,
+  the class redefinition will fail when SB-PCL::REMOVE-READER-METHOD
+  tries to find and remove a method with an incompatible lambda list
+  from the unrelated generic function.