0.8.21.2:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 49b4c25..bc3eebd 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))

@@ -379,24 +353,6 @@ WORKAROUND:
    a STYLE-WARNING for references to variables similar to locals might
    be a good thing.)
 
    a STYLE-WARNING for references to variables similar to locals might
    be a good thing.)
 

-125:
-   (as reported by Gabe Garza on cmucl-help 2001-09-21)
-       (defvar *tmp* 3)
-       (defun test-pred (x y)
-         (eq x y))
-       (defun test-case ()
-         (let* ((x *tmp*)
-                (func (lambda () x)))
-           (print (eq func func))
-           (print (test-pred func func))
-           (delete func (list func))))
-   Now calling (TEST-CASE) gives output
-     NIL
-     NIL
-     (#<FUNCTION {500A9EF9}>)
-   Evidently Python thinks of the lambda as a code transformation so
-   much that it forgets that it's also an object.
-

 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,

@@ -931,6 +887,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 ()

@@ -1170,16 +1134,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.

@@ -1569,6 +1523,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.

@@ -1581,6 +1539,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

@@ -2056,3 +2021,79 @@ WORKAROUND:
            (let ((i (sb-c::values-type-intersection x y)))
              (assert (sb-c::type= i (sb-c::values-type-intersection i x)))
              (assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))
            (let ((i (sb-c::values-type-intersection x y)))
              (assert (sb-c::type= i (sb-c::values-type-intersection i x)))
              (assert (sb-c::type= i (sb-c::values-type-intersection i y)))))))

+
+370: reader misbehaviour on large-exponent floats
+    (read-from-string "1.0s1000000000000000000000000000000000000000")
+  causes the reader to attempt to create a very large bignum (which it
+  will then attempt to coerce to a rational).  While this isn't
+  completely wrong, it is probably not ideal -- checking the floating
+  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.
+
+373: profiling issues on ppc/darwin
+ The following bit from smoke.impure.lisp fails on ppc/darwin:
+    (progn
+      (defun profiled-fun ()
+        (random 1d0))
+      (profile profiled-fun)
+      (loop repeat 100000 do (profiled-fun))
+      (report))
+ dropping into the debugger with a TYPE-ERROR:
+    The value -1073741382 is not of type UNSIGNED-BYTE.
+ The test has been disabled on Darwin till the bug is fixed.
+
+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.