0.8.3.39:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 4582384..13c5cc4 100644 (file)
--- a/BUGS
+++ b/BUGS
@@ -32,8 +32,6 @@ have gone away (typically because they were fixed, but sometimes for
 other reasons, e.g. because they were moved elsewhere).
 
 
 other reasons, e.g. because they were moved elsewhere).
 
 
-KNOWN BUGS OF NO SPECIAL CLASS:
-
 2:
   DEFSTRUCT almost certainly should overwrite the old LAYOUT information
   instead of just punting when a contradictory structure definition
 2:
   DEFSTRUCT almost certainly should overwrite the old LAYOUT information
   instead of just punting when a contradictory structure definition
@@ -170,12 +168,6 @@ 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:
-       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)
        c: Many expressions generate floating infinity on x86/Linux:
                (/ 1 0.0)
                (/ 1 0.0d0)
@@ -196,7 +188,10 @@ WORKAROUND:
   type safety errors reported by Peter Van Eynde July 25, 2000:
        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
   type safety errors reported by Peter Van Eynde July 25, 2000:
        k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
           not a binary input stream, but instead cheerfully reads from
-          character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
+          string-input streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
+  [ Bug was reported as "from character streams", but in 0.8.3.10 we
+  get correct behaviour from (WITH-OPEN-FILE (i "/dev/zero") (READ-BYTE i)) ]
+
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
 
 60:
   The debugger LIST-LOCATIONS command doesn't work properly.
@@ -366,6 +361,8 @@ WORKAROUND:
   your pre-0.7.0 state of grace with
     #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
 
   your pre-0.7.0 state of grace with
     #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
 
+  (see also bug 279)
+
 118:
    as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
      (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
 118:
    as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
      (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
@@ -496,6 +493,7 @@ WORKAROUND:
   it took more than two minutes (but less than five) for me.
 
 145:
   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
   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 +501,18 @@ WORKAROUND:
   conformance problem, since seems hard to construct useful code
   where it matters.)
 
   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, 
 146:
   Floating point errors are reported poorly. E.g. on x86 OpenBSD
   with sbcl-0.7.1, 
@@ -535,6 +545,8 @@ WORKAROUND:
   isn't too surprising since there are many differences in stack
   implementation and GC conservatism between the X86 and other ports.)
 
   isn't too surprising since there are many differences in stack
   implementation and GC conservatism between the X86 and other ports.)
 
+  This is probably the same bug as 216
+
 167:
   In sbcl-0.7.3.11, compiling the (illegal) code 
     (in-package :cl-user)
 167:
   In sbcl-0.7.3.11, compiling the (illegal) code 
     (in-package :cl-user)
@@ -789,6 +801,8 @@ WORKAROUND:
   the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
   not be the actual problem. (CMU CL 18c doesn't have problems with this.)
 
   the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
   not be the actual problem. (CMU CL 18c doesn't have problems with this.)
 
+  This is probably the same bug as 162
+
 217: "Bad type operations with FUNCTION types"
   In sbcl.0.7.7:
 
 217: "Bad type operations with FUNCTION types"
   In sbcl.0.7.7:
 
@@ -815,20 +829,6 @@ WORKAROUND:
   produce invalid code, but type checking is not accurate.)
 
 233: bugs in constraint propagation
   produce invalid code, but type checking is not accurate.)
 
 233: bugs in constraint propagation
-  a.
-  (defun foo (x)
-    (declare (optimize (speed 2) (safety 3)))
-    (let ((y 0d0))
-      (values
-       (the double-float x)
-       (setq y (+ x 1d0))
-       (setq x 3d0)
-       (quux y (+ y 2d0) (* y 3d0)))))
-  (foo 4) => segmentation violation
-
-  (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS)
-  (see also bug 236)
-
   b.
   (declaim (optimize (speed 2) (safety 3)))
   (defun foo (x y)
   b.
   (declaim (optimize (speed 2) (safety 3)))
   (defun foo (x y)
@@ -1057,16 +1057,192 @@ WORKAROUND:
         (bignum "hip")
         (t "zuz")))
 
         (bignum "hip")
         (t "zuz")))
 
-271:
-  Cross-compiler cannot perform constant folding of some internal
-  functions, such as %NEGATE.
+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. (If you like magic and want to
+  fix it, don't forget to change all uses of MACROEXPAND to
+  MACROEXPAND*.)
+
+275:
+  The following code (taken from CLOCC) takes a lot of time to compile:
 
 
-272:
-  All forms of GC hooks (including notifiers and finalisers) are currently
-  (since 0.8.0) broken for gencgc (i.e. x86) users 
+    (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)
 
 
-DEFUNCT CATEGORIES OF BUGS
-  IR1-#:
-    These labels were used for bugs related to the old IR1 interpreter.
-    The # values reached 6 before the category was closed down.
+276:
+    (defmethod fee ((x fixnum))
+      (setq x (/ x 2))
+      x)
+    (fee 1) => type error
+
+  (taken from CLOCC)
+
+278:
+  a.
+    (defun foo ()
+      (declare (optimize speed))
+      (loop for i of-type (integer 0) from 0 by 2 below 10
+            collect i))
+
+  uses generic arithmetic.
+
+  b. For the example above, the compiler does not issue a note.
+     (fixed in 0.8.3.6, but a test case would be good)
+
+279: type propagation error -- correctly inferred type goes astray?
+  In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
+       The binding of ABS-FOO is a (VALUES (INTEGER 0 0)
+       &OPTIONAL), not a (INTEGER 1 536870911)
+  is emitted when compiling this file:
+    (declaim (ftype (function ((integer 0 #.most-positive-fixnum))
+                              (integer #.most-negative-fixnum 0))
+                    foo))
+    (defun foo (x)
+      (- x))
+    (defun bar (x)
+      (let* (;; Uncomment this for a type mismatch warning indicating 
+             ;; that the type of (FOO X) is correctly understood.
+             #+nil (fs-foo (float-sign (foo x)))
+                   ;; Uncomment this for a type mismatch warning 
+                   ;; indicating that the type of (ABS (FOO X)) is
+                   ;; correctly understood.
+             #+nil (fs-abs-foo (float-sign (abs (foo x))))
+             ;; something wrong with this one though
+             (abs-foo (abs (foo x))))
+        (declare (type (integer 1 100) abs-foo))
+        (print abs-foo)))
+
+ (see also bug 117)
+
+280: bogus WARNING about duplicate function definition 
+  In sbcl-0.8.3 and sbcl-0.8.1.47, if BS.MIN is defined inline,
+  e.g. by 
+     (declaim (inline bs.min))
+     (defun bs.min (bases) nil)
+  before compiling the file below, the compiler warns
+     Duplicate definition for BS.MIN found in one static
+     unit (usually a file).
+  when compiling 
+    (declaim (special *minus* *plus* *stagnant*))
+    (defun b.*.min (&optional (x () xp) (y () yp) &rest rest)
+      (bs.min avec))
+    (define-compiler-macro b.*.min (&rest rest)
+      `(bs.min ,@rest))
+    (defun afish-d-rbd (pd)
+      (if *stagnant* 
+          (b.*.min (foo-d-rbd *stagnant*))
+          (multiple-value-bind (reduce-fn initial-value)
+              (etypecase pd
+                (list (values #'bs.min 0))
+                (vector (values #'bs.min *plus*)))
+            (let ((cv-ks (cv (kpd.ks pd))))
+              (funcall reduce-fn d-rbds)))))
+    (defun bfish-d-rbd (pd)
+      (if *stagnant* 
+          (b.*.min (foo-d-rbd *stagnant*))
+          (multiple-value-bind (reduce-fn initial-value)
+              (etypecase pd
+                (list (values #'bs.min *minus*))
+                (vector (values #'bs.min 0)))
+            (let ((cv-ks (cv (kpd.ks pd))))
+              (funcall reduce-fn d-rbds)))))
+
+281: COMPUTE-EFFECTIVE-METHOD error signalling.
+  (slightly obscured by a non-0 default value for
+   SB-PCL::*MAX-EMF-PRECOMPUTE-METHODS*)
+  It would be natural for COMPUTE-EFFECTIVE-METHOD to signal errors
+  when it finds a method with invalid qualifiers.  However, it
+  shouldn't signal errors when any such methods are not applicable to
+  the particular call being evaluated, and certainly it shouldn't when
+  simply precomputing effective methods that may never be called.
+  (setf sb-pcl::*max-emf-precompute-methods* 0)
+  (defgeneric foo (x)
+    (:method-combination +)
+    (:method ((x symbol)) 1)
+    (:method + ((x number)) x))
+  (foo 1) -> ERROR, but should simply return 1
+
+  The issue seems to be that construction of a discriminating function
+  calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable.
+
+282: "type checking in full calls"
+  In current (0.8.3.6) implementation a CAST in a full call argument
+  is not checked; but the continuation between the CAST and the
+  combination has the "checked" type and CAST performs unsafe
+  coercion; this may lead to errors: if FOO is declared to take a
+  FIXNUM, this code will produce garbage on a machine with 30-bit
+  fixnums:
+
+    (foo (aref (the (array (unsigned-byte 32)) x)))
+
+283: Thread safety: libc functions
+  There are places that we call unsafe-for-threading libc functions
+  that we should find alternatives for, or put locks around.  Known or
+  strongly suspected problems, as of 0.8.3.10: please update this
+  bug instead of creating new ones
+
+    localtime() - called for timezone calculations in code/time.lisp
+
+284: Thread safety: special variables
+  There are lots of special variables in SBCL, and I feel sure that at
+  least some of them are indicative of potentially thread-unsafe 
+  parts of the system.  See doc/internals/notes/threading-specials
+
+285: PPC randomness
+  In SBCL 0.8.3.1x on a powerpc running Linux (dunno if Darwin is
+    similarly affected):
+  * (dotimes (i 100) (random 1663553320000000))
+
+  NIL
+  * (dotimes (i 100) (random 1663553340000000))
+
+  NIL
+  * (dotimes (i 100) (random 1663553350000000))
+
+  debugger invoked on condition of type TYPE-ERROR:
+    The value -30653269094906
+      is not of type
+      (OR (SINGLE-FLOAT 0.0) (DOUBLE-FLOAT 0.0d0) (RATIONAL 0)).
+
+    and, weirdly, the frame is:
+  ("hairy arg processor for top level local call RANDOM"
+   1663553347392000
+   #S(RANDOM-STATE
+      :STATE #(0 2567483615 188 1503590015 2333049409 322761517 ...)))
+
+  (the type error doesn't seem to be terribly deterministic in when it
+  occurs.  Bigger numbers seem better able to trigger the error)
+
+286: "recursive known functions"
+  Self-call recognition conflicts with known function
+  recognition. Currently cross compiler and target COMPILE do not
+  recognize recursion, and in target compiler it can be disabled. We
+  can always disable it for known functions with RECURSIVE attribute,
+  but there remains a possibility of a function with a
+  (tail)-recursive simplification pass and transforms/VOPs for base
+  cases.
+
+287: PPC/Linux miscompilation or corruption in first GC
+  When the runtime is compiled with -O3 on certain PPC/Linux machines, a
+  segmentation fault is reported at the point of first triggered GC,
+  during the compilation of DEFSTRUCT WRAPPER.  As a temporary workaround,
+  the runtime is no longer compiled with -O3 on PPC/Linux, but it is likely
+  that this merely obscures, not solves, the underlying problem; as and when
+  underlying problems are fixed, it would be worth trying again to provoke
+  this problem.