0.8.3.39:
[sbcl.git] / BUGS
diff --git a/BUGS b/BUGS
index 7586950..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.
@@ -223,12 +218,6 @@ WORKAROUND:
   crashes SBCL. In general tracing anything which is used in the 
   implementation of TRACE is likely to have the same problem.
 
   crashes SBCL. In general tracing anything which is used in the 
   implementation of TRACE is likely to have the same problem.
 
-75:
-  As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
-  ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
-  :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
-  WITH-OUTPUT-TO-STRING.
-
 78:
   ANSI says in one place that type declarations can be abbreviated even
   when the type name is not a symbol, e.g.
 78:
   ANSI says in one place that type declarations can be abbreviated even
   when the type name is not a symbol, e.g.
@@ -276,34 +265,6 @@ WORKAROUND:
   holding... * is not equivalent to T in many cases, such as 
     (VECTOR *) /= (VECTOR T).
 
   holding... * is not equivalent to T in many cases, such as 
     (VECTOR *) /= (VECTOR T).
 
-94a: 
-  Inconsistencies between derived and declared VALUES return types for
-  DEFUN aren't checked very well. E.g. the logic which successfully
-  catches problems like
-    (declaim (ftype (function (fixnum) float) foo))
-    (defun foo (x)
-      (declare (type integer x))
-      (values x)) ; wrong return type, detected, gives warning, good!
-  fails to catch
-    (declaim (ftype (function (t) (values t t)) bar))
-    (defun bar (x)
-      (values x)) ; wrong number of return values, no warning, bad!
-  The cause of this is seems to be that (1) the internal function 
-  VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
-  arguments symmetrically, and (2) when the type checking code was
-  written back when when SBCL's code was still CMU CL, the intent
-  was that this case
-    (declaim (ftype (function (t) t) bar))
-    (defun bar (x)
-      (values x x)) ; wrong number of return values; should give warning?
-  not be warned for, because a two-valued return value is considered
-  to be compatible with callers who expects a single value to be
-  returned. That intent is probably not appropriate for modern ANSI
-  Common Lisp, but fixing this might be complicated because of other
-  divergences between auld-style and new-style handling of
-  multiple-VALUES types. (Some issues related to this were discussed
-  on cmucl-imp at some length sometime in 2000.)
-
 95:
   The facility for dumping a running Lisp image to disk gets confused
   when run without the PURIFY option, and creates an unnecessarily large
 95:
   The facility for dumping a running Lisp image to disk gets confused
   when run without the PURIFY option, and creates an unnecessarily large
@@ -400,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)
@@ -530,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
@@ -537,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, 
@@ -569,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)
@@ -823,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:
 
@@ -846,38 +826,9 @@ WORKAROUND:
    Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
 
   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
    Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
 
   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
-  produce invalid code, but type checking is not accurate. Similar
-  problems exist with VALUES-TYPE-INTERSECTION.)
-
-220:
-  Sbcl 0.7.9 fails to compile
-
-  (multiple-value-call #'list
-    (the integer (helper))
-    nil)
-
-  Type check for INTEGER, the result of which serves as the first
-  argument of M-V-C, is inserted after evaluation of NIL. So arguments
-  of M-V-C are pushed in the wrong order. As a temporary workaround
-  type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
-  would be to put the check between evaluation of arguments, but it
-  could be tricky to check result types of PROG1, IF etc.
+  produce invalid code, but type checking is not accurate.)
 
 233: bugs in constraint propagation
 
 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)
@@ -1067,26 +1018,231 @@ WORKAROUND:
 
   Urgh... It's time to write IR1-copier.
 
 
   Urgh... It's time to write IR1-copier.
 
-262:
-  In 0.8.1.32:
+265:
+  SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC;
+  attempting to use it leads to segmentation violations.  This is
+  probably because of a bogus implementation of
+  os_restore_fp_control().
 
 
-    * (ensure-generic-function 'foo)
-    #<STANDARD-GENERIC-FUNCTION FOO (0)>
-    * (defmethod foo (x) x)
-    debugger invoked on condition of type SIMPLE-ERROR:
-      The generic function #<STANDARD-GENERIC-FUNCTION FOO (0)> takes 0 required
-      arguments; was asked to find a method with specializers (#<BUILT-IN-CLASS T>)
+266:
+  David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
+  behaviour of streams with element-type (SIGNED-BYTE 8).  The patch
+  looks reasonable, if not obviously correct; however, it caused the
+  PPC/Linux port to segfault during warm-init while loading
+  src/pcl/std-class.fasl.  A workaround patch was made, but it would
+  be nice to understand why the first patch caused problems, and to
+  fix the cause if possible.
 
 
-  AMOP seems to say that it should work (first ADD-METHOD initializes
-  GF lambda list).
+268: "wrong free declaration scope"
+  The following code must signal type error:
 
 
-263:
-  :PREFIX, :PER-LINE-PREFIX and :SUFFIX arguments of
-  PPRINT-LOGICAL-BLOCK may be complex strings.
+    (locally (declare (optimize (safety 3)))
+      (flet ((foo (x &optional (y (car x)))
+               (declare (optimize (safety 0)))
+               (list x y)))
+        (funcall (eval #'foo) 1)))
 
 
-  (fixed in 0.8.1.33)
+269:
+  SCALE-FLOAT should accept any integer for its second argument.
 
 
-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.
+270:
+  In the following function constraint propagator optimizes nothing:
+
+    (defun foo (x)
+      (declare (integer x))
+      (declare (optimize speed))
+      (typecase x
+        (fixnum "hala")
+        (fixnum "buba")
+        (bignum "hip")
+        (t "zuz")))
+
+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:
+
+    (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)
+
+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.