X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=BUGS;h=41587108cd0f12d6586a59e47cbef9c4c2f844b7;hb=57e21c4b62e8c1a1ee7ef59ed2abb0c864fb06bc;hp=545ec9cbbda1d92836f9bd56bf8b45d8b774ccd3;hpb=10e7ad98e711db20ada209a4be37f06c466cfbe8;p=sbcl.git diff --git a/BUGS b/BUGS index 545ec9c..4158710 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 @@ -1206,27 +1193,55 @@ WORKAROUND: 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. + +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.