X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=inline;f=BUGS;h=94a87e1743b67aafc5c69ef352df963c919f476b;hb=947522ee16a30d43466c8f86efacee7003e5d85f;hp=fb6a1433e1b49ff4978db02d97fc6175b9989355;hpb=18d4de696bc5063aad026ba62be613c7b07f5fc8;p=sbcl.git

diff --git a/BUGS b/BUGS
index fb6a143..94a87e1 100644
--- a/BUGS
+++ b/BUGS
@@ -1098,6 +1098,102 @@ Error in function C::GET-LAMBDA-TO-COMPILE:
   your pre-0.7.0 state of grace with
     #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
 
+118:
+   as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
+     (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
+        (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
+   when of course it should be NIL. (He says it only fails for X86,
+   not SPARC; dunno about Alpha.)
+
+   Also, "the same problem exists for LONG-FLOAT-EPSILON,
+   DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
+   for the -negative- the + is replaced by a - in the test)."
+
+   Raymond Toy comments that this is tricky on the X86 since its FPU
+   uses 80-bit precision internally.
+
+119:
+   a bug in the byte compiler and/or interpreter: Compile
+	(IN-PACKAGE :CL-USER)
+	(DECLAIM (OPTIMIZE (SPEED 0) (SAFETY 1) (DEBUG 1)))
+	(DEFUN BAR (&REST DIMS)
+	  (IF (EVERY #'INTEGERP DIMS)
+	      1
+	      2))
+   then execute (BAR '(1 2 3 4)). In sbcl-0.pre7.14.flaky4.8
+   this gives a TYPE-ERROR,
+     The value #:UNINITIALIZED-EVAL-STACK-ELEMENT is not
+	of type (MOD 536870911).
+   The same error will probably occur in earlier versions as well, 
+   although the name of the uninitialized-element placeholder will
+   be shorter.
+
+   The same thing happens if the compiler macro expansion of 
+   EVERY into MAP is hand-expanded:
+	(defun bar2 (dims)
+	  (if (block blockname
+		(map nil
+		     (lambda (dim)
+		       (let ((pred-value (funcall #'integerp dim)))
+			 (unless pred-value
+			   (return-from blockname
+			     nil))))
+		     dims)	
+		t)
+	      1
+	      2))
+   CMU CL doesn't have this compiler macro expansion, so it was 
+   immune to the original bug in BAR, but once we hand-expand it
+   into BAR2, CMU CL 18c has the same bug. (Run (BAR '(NIL NIL)).)
+
+   The native compiler handles it fine, both in SBCL and in CMU CL.
+
+120a:
+   The compiler incorrectly figures the return type of 
+	(DEFUN FOO (FRAME UP-FRAME)
+	  (IF (OR (NOT FRAME)
+		  T)
+	      FRAME
+	      "BAR"))
+   as NIL.
+
+   This problem exists in CMU CL 18c too. When I reported it on
+   cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with 
+   a partial explanation, but no fix has been found yet.
+
+120b:
+   Even in sbcl-0.pre7.x, which is supposed to be free of the old
+   non-ANSI behavior of treating the function return type inferred
+   from the current function definition as a declaration of the
+   return type from any function of that name, the return type of NIL
+   is attached to FOO in 120a above, and used to optimize code which
+   calls FOO. 
+
+121:
+  In sbcl-0.7.14.flaky4.10, the last MAPTEST test case at the end
+  of tests/map-tests.impure.lisp dies with 
+	  The value
+	    #<SB-C::MV-COMBINATION
+	      :FUN #<SB-C::REF
+	             :LEAF #<SB-C::GLOBAL-VAR
+	                     :NAME +
+	                     :TYPE #
+	                     :WHERE-FROM :DECLARED
+	                     :KIND :GLOBAL-FUNCTION>>
+	      :ARGS (#<SB-C::COMBINATION :FUN # :ARGS (#)>)>
+	  is not of type
+	    SB-C::COMBINATION.
+  in 
+	(SB-C::GENERATE-BYTE-CODE-FOR-REF
+	 #<SB-ASSEM:SEGMENT :NAME "Byte Output">
+	 #<SB-C::REF
+	   :LEAF #<SB-C::GLOBAL-VAR
+	           :NAME +
+	           :TYPE #<SB-KERNEL:FUNCTION-TYPE (FUNCTION # NUMBER)>
+	           :WHERE-FROM :DECLARED
+	           :KIND :GLOBAL-FUNCTION>>
+	 #<SB-C::CONTINUATION {506AD995}>)
+
 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 
 (Note: At some point, the pure interpreter (actually a semi-pure
@@ -1171,14 +1267,6 @@ IR1-4:
   interpreter is gone, the system's notion of what's a top-level form
   and what's not will remain too confused to fix this problem.]
 
-IR1-5:
-  (not really a bug, just a wishlist thing which might be easy
-  when EVAL-WHEN is rewritten..) It might be good for the cross-compiler
-  to warn about nested EVAL-WHENs. (In ordinary compilation, they're
-  quite likely to be OK, but in cross-compiled code EVAL-WHENs
-  are a great source of confusion, so a style warning about anything
-  unusual could be helpful.)
-
 IR1-6:
   (another wishlist thing..) Reimplement DEFMACRO to be basically
   like DEFMACRO-MUNDANELY, just using EVAL-WHEN.