X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=788da3e6cdf1a77920485fbb01128d60ad52b6c7;hb=1b56edad1bf47547bbcd3b98c809b6f933ba937e;hp=a20b8ff66769d1c94f799abb38d69ce97988c57c;hpb=3fcdd6d5413993b47ab7c3060d52eefd04a5fabb;p=sbcl.git

diff --git a/BUGS b/BUGS
index a20b8ff..788da3e 100644
--- a/BUGS
+++ b/BUGS
@@ -501,17 +501,7 @@ 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))
+  b. (fixed in 0.8.3.43)
 
 146:
   Floating point errors are reported poorly. E.g. on x86 OpenBSD
@@ -1072,7 +1062,9 @@ WORKAROUND:
 
 274:
   CLHS says that type declaration of a symbol macro should not affect
-  its expansion, but in SBCL it does.
+  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:
@@ -1091,10 +1083,6 @@ WORKAROUND:
 
   (taken from CLOCC)
 
-277:
-  IGNORE/IGNORABLE declarations should be acceptable for symbol
-  macros.
-
 278:
   a.
     (defun foo ()
@@ -1104,8 +1092,7 @@ WORKAROUND:
 
   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)
+  b. (fixed in 0.8.3.6)
 
 279: type propagation error -- correctly inferred type goes astray?
   In sbcl-0.8.3 and sbcl-0.8.1.47, the warning
@@ -1205,3 +1192,69 @@ WORKAROUND:
   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
+
+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.
+
+288: fundamental cross-compilation issues (from old UGLINESS file)
+  288a: Using host floating point numbers to represent target
+    floating point numbers, or host characters to represent
+    target characters, is theoretically shaky. (The characters
+    are OK as long as the characters are in the ANSI-guaranteed
+    character set, though, so they aren't a real problem as
+    long as the sources don't need anything but that.)
+  288b: The compiler still makes assumptions about cross-compilation-host
+    implementation of ANSI CL:
+    288b1: Simple bit vectors are distinct from simple vectors (in
+	DEFINE-STORAGE-BASE and elsewhere). (Actually, I'm not *sure*
+	that things would really break if this weren't so, but I 
+	strongly suspect that they would.)
+    288b2: SINGLE-FLOAT is distinct from DOUBLE-FLOAT. (This is 
+	in a sense just one aspect of bug 288a.)
+
+289: "type checking and source-transforms"
+  a.
+    (block nil (let () (funcall #'+ (eval 'nil) (eval '1) (return :good))))
+  signals type error.
+
+  Our policy is to check argument types at the moment of a call. It
+  disagrees with ANSI, which says that type assertions are put
+  immediately onto argument expressions, but is easier to implement in
+  IR1 and is more compatible to type inference, inline expansion,
+  etc. IR1-transforms automatically keep this policy, but source
+  transforms for associative functions (such as +), being applied
+  during IR1-convertion, do not. It may be tolerable for direct calls
+  (+ x y z), but for (FUNCALL #'+ x y z) it is non-conformant.
+
+  b. Another aspect of this problem is efficiency. [x y + z +]
+  requires less registers than [x y z + +]. This transformation is
+  currently performed with source transforms, but it would be good to
+  also perform it in IR1 optimization phase.
+
+290: Alpha floating point and denormalized traps
+  In SBCL 0.8.3.6x on the alpha, we work around what appears to be a
+  hardware or kernel deficiency: the status of the enable/disable
+  denormalized-float traps bit seems to be ambiguous; by the time we
+  get to os_restore_fp_control after a trap, denormalized traps seem
+  to be enabled.  Since we don't want a trap every time someone uses a
+  denormalized float, in general, we mask out that bit when we restore
+  the control word; however, this clobbers any change the user might
+  have made.
+
+292:
+  (fixed in 0.8.3.74)