0.8.2.55:

[sbcl.git] / BUGS

diff --git a/BUGS b/BUGS
index 4582384..84357b1 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -170,12 +170,6 @@ WORKAROUND:
 45:
   a slew of floating-point-related errors reported by Peter Van Eynde
   on July 25, 2000:
-       b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT on the x86 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 on x86/Linux:
                (/ 1 0.0)
                (/ 1 0.0d0)
@@ -496,6 +490,7 @@ WORKAROUND:
   it took more than two minutes (but less than five) for me.
 
 145:
+  a.
   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
@@ -503,6 +498,18 @@ WORKAROUND:
   conformance problem, since seems hard to construct useful code
   where it matters.)
 
+  b.
+  * (defun foo (x)
+      (declare (type (double-float -0d0) x))
+      (declare (optimize speed))
+      (+ x (sqrt (log (random 1d0)))))
+  debugger invoked on condition of type SIMPLE-ERROR:
+    bad thing to be a type specifier: ((COMPLEX
+                                        (DOUBLE-FLOAT 0.0d0
+                                                      #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY))
+                                       #C(0.0d0 #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY)
+                                       #C(0.0d0 #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY))
+
 146:
   Floating point errors are reported poorly. E.g. on x86 OpenBSD
   with sbcl-0.7.1, 
@@ -1057,14 +1064,48 @@ WORKAROUND:
         (bignum "hip")
         (t "zuz")))
 
-271:
-  Cross-compiler cannot perform constant folding of some internal
-  functions, such as %NEGATE.
-
 272:
   All forms of GC hooks (including notifiers and finalisers) are currently
   (since 0.8.0) broken for gencgc (i.e. x86) users 
 
+273:
+  Compilation of the following two forms causes "X is unbound" error:
+
+    (symbol-macrolet ((x pi))
+      (macrolet ((foo (y) (+ x y)))
+        (declaim (inline bar))
+        (defun bar (z)
+          (* z (foo 4)))))
+    (defun quux (z)
+      (bar z))
+
+  (See (COERCE (CDR X) 'FUNCTION) in IR1-CONVERT-INLINE-LAMBDA.)
+
+274:
+  CLHS says that type declaration of a symbol macro should not affect
+  its expansion, but in SBCL it does.
+
+275:
+  The following code (taken from CLOCC) takes a lot of time to compile:
+
+    (defun foo (n)
+      (declare (type (integer 0 #.large-constant) n))
+      (expt 1/10 n))
+
+  (fixed in 0.8.2.51, but a test case would be good)
+
+276:
+    (defmethod fee ((x fixnum))
+      (setq x (/ x 2))
+      x)
+    (fee 1) => type error
+
+  (taken from CLOCC)
+
+277:
+  IGNORE/IGNORABLE declarations should be acceptable for symbol
+  macros.
+
 
 DEFUNCT CATEGORIES OF BUGS
   IR1-#: