X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=2917c5c0de079278900137b8f69c0303b698b00b;hb=c43e3ee7e99bf8116402c2e6a90320b2e92b391b;hp=963ff68273c69f064bc247fca3180c242d9976c0;hpb=a0c5831b3a74118cf41a848300200a1acdb48dcf;p=sbcl.git

diff --git a/BUGS b/BUGS
index 963ff68..2917c5c 100644
--- a/BUGS
+++ b/BUGS
@@ -883,11 +883,9 @@ WORKAROUND:
 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
+  strongly suspected problems, as of 1.0.3.13: please update this
   bug instead of creating new ones
 
-    gethostbyname, gethostbyaddr in sb-bsd-sockets
-
 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 
@@ -1723,3 +1721,93 @@ WORKAROUND:
  as of 0.9.18.11 the file compiler breaks on it:
   failed AVER: "(NOT (FUNCTIONAL-HAS-EXTERNAL-REFERENCES-P CLAMBDA))"
  Defining the missing MAKE-LOAD-FORM method makes the error go away.
+
+407: misoptimization of loop, COERCE 'FLOAT, and HANDLER-CASE for bignums
+  (reported by Ariel Badichi on sbcl-devel 2007-01-09)
+  407a: In sbcl-1.0.1 on Linux x86, 
+		(defun foo ()
+		  (loop for n from (expt 2 1024) do
+		        (handler-case
+		            (coerce n 'single-float)
+		          (simple-type-error ()
+		            (format t "Got here.~%")
+		            (return-from foo)))))
+		(foo)
+        causes an infinite loop, where handling the error would be expected.
+  407b: In sbcl-1.0.1 on Linux x86, 
+		(defun bar ()
+		  (loop for n from (expt 2 1024) do
+		        (handler-case
+		            (format t "~E~%" (coerce n 'single-float))
+		          (simple-type-error ()
+		            (format t "Got here.~%")
+		            (return-from bar)))))
+        fails to compile, with
+		Too large to be represented as a SINGLE-FLOAT: ...
+	from
+		0: ((LABELS SB-BIGNUM::CHECK-EXPONENT) ...)
+		1: ((LABELS SB-BIGNUM::FLOAT-FROM-BITS) ...)
+		2: (SB-KERNEL:%SINGLE-FLOAT ...)
+		3: (SB-C::BOUND-FUNC ...)
+		4: (SB-C::%SINGLE-FLOAT-DERIVE-TYPE-AUX ...)
+
+408: SUBTYPEP confusion re. OR of SATISFIES of not-yet-defined predicate
+	As reported by Levente M\'{e}sz\'{a}ros sbcl-devel 2006-02-20,
+		(aver (equal (multiple-value-list
+	                      (subtypep '(or (satisfies x) string)
+        	                        '(or (satisfies x) integer)))
+	                     '(nil nil)))
+	fails. Also, beneath that failure lurks another failure,
+		(aver (equal (multiple-value-list
+                              (subtypep 'string
+	                                '(or (satisfies x) integer)))
+		             '(nil nil)))
+	Having looked at this for an hour or so in sbcl-1.0.2, and
+	specifically having looked at the output from
+	  laptop$ sbcl
+	  * (let ((x 'string)
+	          (y '(or (satisfies x) integer)))
+	      (trace sb-kernel::union-complex-subtypep-arg2
+	             sb-kernel::invoke-complex-subtypep-arg1-method
+	             sb-kernel::type-union
+	             sb-kernel::type-intersection
+	             sb-kernel::type=)
+	      (subtypep x y))
+	my (WHN) impression is that the problem is that the semantics of TYPE=
+	are wrong for what the UNION-COMPLEX-SUBTYPEP-ARG2 code is trying
+	to use it for. The comments on the definition of TYPE= probably
+	date back to CMU CL and seem to define it as a confusing thing:
+	its primary value is something like "certainly equal," and its
+	secondary value is something like "certain about that certainty."
+	I'm left uncertain how to fix UNION-COMPLEX-SUBTYPEP-ARG2 without
+	reducing its generality by removing the TYPE= cleverness. Possibly
+	the tempting TYPE/= relative defined next to it might be a
+	suitable replacement for the purpose. Probably, though, it would
+	be best to start by reverse engineering exactly what TYPE= and
+	TYPE/= do, and writing an explanation which is so clear that one
+	can see immediately what it's supposed to mean in odd cases like
+	(TYPE= '(SATISFIES X) 'INTEGER) when X isn't defined yet.
+
+409: MORE TYPE SYSTEM PROBLEMS
+  Found while investigating an optimization failure for extended
+  sequences. The extended sequence type implementation was altered to
+  work around the problem, but the fundamental problem remains, to wit:
+    (sb-kernel:type= (sb-kernel:specifier-type '(or float ratio))
+                     (sb-kernel:specifier-type 'single-float))
+  returns NIL, NIL on sbcl-1.0.3.
+  (probably related to bug #408)
+
+410: read circularities and type declarations
+  Consider the definition
+    (defstruct foo (a 0 :type (not symbol)))
+  followed by
+    (setf *print-circle* t) ; just in case
+    (read-from-string "#1=#s(foo :a #1#)")
+  This gives a type error (#:G1 is not a (NOT SYMBOL)) because of the
+  implementation of read circularity, using a symbol as a marker for
+  the previously-referenced object.
+
+411: NAN issues on x86-64
+  Test :NAN-COMPARISONS in float.pure.lisp fails on x86-64, and has been
+  disabled on those platforms. Since x86 does not exhibit any problems
+  the problem is probably with the new FP implementation.