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

diff --git a/BUGS b/BUGS
index a20b8ff..13c5cc4 100644
--- a/BUGS
+++ b/BUGS
@@ -1072,7 +1072,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 +1093,6 @@ WORKAROUND:
 
   (taken from CLOCC)
 
-277:
-  IGNORE/IGNORABLE declarations should be acceptable for symbol
-  macros.
-
 278:
   a.
     (defun foo ()
@@ -1205,3 +1203,46 @@ 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
+
+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.