X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=788da3e6cdf1a77920485fbb01128d60ad52b6c7;hb=227096b878fee7afae9d3bc2cee5df01449bca2d;hp=eb66e35736be2fc8444506600bde28282a810a78;hpb=d9e8b9ff41d7eedf7401fc7c8b473318a1ce33d4;p=sbcl.git

diff --git a/BUGS b/BUGS
index eb66e35..788da3e 100644
--- a/BUGS
+++ b/BUGS
@@ -1210,3 +1210,51 @@ WORKAROUND:
   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)