X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=eb66e35736be2fc8444506600bde28282a810a78;hb=4f102592a1c122f17231563671930456c7c85f5c;hp=a20b8ff66769d1c94f799abb38d69ce97988c57c;hpb=3fcdd6d5413993b47ab7c3060d52eefd04a5fabb;p=sbcl.git diff --git a/BUGS b/BUGS index a20b8ff..eb66e35 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,21 @@ 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.