X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=f47e869efa0495e97887dcbb2b59dc7dcd437dae;hb=dcf5978d9d33098e868ae6eea28e1b310038c03d;hp=6b0a4f37b842475d6186bc6030bdeba3e6e5cf7b;hpb=c58795f37078f5900aff5dc4a3712fbadd2d432e;p=sbcl.git diff --git a/BUGS b/BUGS index 6b0a4f3..f47e869 100644 --- a/BUGS +++ b/BUGS @@ -32,8 +32,6 @@ have gone away (typically because they were fixed, but sometimes for other reasons, e.g. because they were moved elsewhere). -KNOWN BUGS OF NO SPECIAL CLASS: - 2: DEFSTRUCT almost certainly should overwrite the old LAYOUT information instead of just punting when a contradictory structure definition @@ -186,12 +184,6 @@ WORKAROUND: (FLOAT 1 DOUBLE-FLOAT-EPSILON) don't give the right behavior. -46: - type safety errors reported by Peter Van Eynde July 25, 2000: - k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is - not a binary input stream, but instead cheerfully reads from - character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc"). - 60: The debugger LIST-LOCATIONS command doesn't work properly. (How should it work properly?) @@ -376,14 +368,6 @@ WORKAROUND: Raymond Toy comments that this is tricky on the X86 since its FPU uses 80-bit precision internally. -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. - 124: As of version 0.pre7.14, SBCL's implementation of MACROLET makes the entire lexical environment at the point of MACROLET available @@ -463,11 +447,9 @@ WORKAROUND: * '``(FOO ,@',@S) ``(FOO SB-IMPL::BACKQ-COMMA-AT S) - b. - * (write '`(, .ala.) :readably t :pretty t) - `(,.ALA.) - - (note the space between the comma and the point) + c. (reported by Paul F. Dietz) + * '`(lambda ,x) + `(LAMBDA (SB-IMPL::BACKQ-COMMA X)) 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately @@ -500,17 +482,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 @@ -544,6 +516,8 @@ WORKAROUND: isn't too surprising since there are many differences in stack implementation and GC conservatism between the X86 and other ports.) + This is probably the same bug as 216 + 167: In sbcl-0.7.3.11, compiling the (illegal) code (in-package :cl-user) @@ -653,8 +627,7 @@ WORKAROUND: classes). This means that at present erroneous attempts to use WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS won't get the corresponding STYLE-WARNING. - c. the examples in CLHS 7.6.5.1 (regarding generic function lambda - lists and &KEY arguments) do not signal errors when they should. + c. (fixed in 0.8.4.23) 201: "Incautious type inference from compound types" a. (reported by APD sbcl-devel 2002-09-17) @@ -741,11 +714,7 @@ WORKAROUND: all of the arguments are circular is probably desireable). 213: "Sequence functions and type checking" - a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with - various complicated, though recognizeable, CONS types [e.g. - (CONS * (CONS * NULL)) - which according to ANSI should be recognized] (and, in SAFETY 3 - code, should return a list of LENGTH 2 or signal an error) + a. (fixed in 0.8.4.36) b. MAP, when given a type argument that is SUBTYPEP LIST, does not check that it will return a sequence of the given type. Fixing it along the same lines as the others (cf. work done around @@ -760,20 +729,6 @@ WORKAROUND: (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2))) can erroneously return T. -214: - SBCL 0.6.12.43 fails to compile - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (flet ((foo (&key (x :vx x-p)) (list x x-p))) - (foo 1 2))) - - or a more simple example: - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x)))) - 215: ":TEST-NOT handling by functions" a. FIND and POSITION currently signal errors when given non-NIL for both their :TEST and (deprecated) :TEST-NOT arguments, but by @@ -798,6 +753,8 @@ WORKAROUND: the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may not be the actual problem. (CMU CL 18c doesn't have problems with this.) + This is probably the same bug as 162 + 217: "Bad type operations with FUNCTION types" In sbcl.0.7.7: @@ -920,10 +877,6 @@ WORKAROUND: a. On X86 an immediate operand for IMUL is printed incorrectly. b. On X86 operand size prefix is not recognized. -248: "reporting errors in type specifier syntax" - (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type - specifier". - 251: (defun foo (&key (a :x)) (declare (fixnum a)) @@ -986,11 +939,6 @@ WORKAROUND: b. The same for CSUBTYPEP. -261: - * (let () (list (the (values &optional fixnum) (eval '(values))))) - debugger invoked on condition of type TYPE-ERROR: - The value NIL is not of type FIXNUM. - 262: "yet another bug in inline expansion of local functions" Compiler fails on @@ -1013,12 +961,6 @@ WORKAROUND: Urgh... It's time to write IR1-copier. -265: - SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC; - attempting to use it leads to segmentation violations. This is - probably because of a bogus implementation of - os_restore_fp_control(). - 266: David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix behaviour of streams with element-type (SIGNED-BYTE 8). The patch @@ -1052,10 +994,6 @@ WORKAROUND: (bignum "hip") (t "zuz"))) -272: - All forms of GC hooks (including notifiers and finalisers) are currently - (since 0.8.0) broken for gencgc (i.e. x86) users - 273: Compilation of the following two forms causes "X is unbound" error: @@ -1071,7 +1009,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: @@ -1090,10 +1030,6 @@ WORKAROUND: (taken from CLOCC) -277: - IGNORE/IGNORABLE declarations should be acceptable for symbol - macros. - 278: a. (defun foo () @@ -1103,8 +1039,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 @@ -1182,17 +1117,114 @@ WORKAROUND: The issue seems to be that construction of a discriminating function calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable. -282: "type checking in full calls" - In current (0.8.3.6) implementation a CAST in a full call argument - is not checked; but the continuation between the CAST and the - combination has the "checked" type and CAST performs unsafe - coercion; this may lead to errors: if FOO is declared to take a - FIXNUM, this code will produce garbage on a machine with 30-bit - fixnums: +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 + bug instead of creating new ones + + localtime() - called for timezone calculations in code/time.lisp + +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 + 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. + +288: fundamental cross-compilation issues (from old UGLINESS file) + 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; + the floats are a real problem.) + +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. + +296: + (reported by Adam Warner, sbcl-devel 2003-09-23) + + The --load toplevel argument does not perform any sanitization of its + argument. As a result, files with Lisp pathname pattern characters + (#\* or #\?, for instance) or quotation marks can cause the system + to perform arbitrary behaviour. + +297: + LOOP with non-constant arithmetic step clauses suffers from overzealous + type constraint: code of the form + (loop for d of-type double-float from 0d0 to 10d0 by x collect d) + compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL + (0))). However, an integral value of X should be legal, because + successive adds of integers to double-floats produces double-floats, + so none of the type restrictions in the code is violated. + +298: (aka PFD MISC.183) + Compiler fails on - (foo (aref (the (array (unsigned-byte 32)) x))) + (defun foo () + (multiple-value-call #'bar + (ext) + (catch 'tag (return-from foo (int))))) + + This program violates "unknown values LVAR stack discipline": if INT + returns, values returned by (EXT) must be removed from under that of + (INT). + +299: (aka PFD MISC.186) + * (defun foo () + (declare (optimize (debug 1))) + (multiple-value-call #'list + (if (eval t) (eval '(values :a :b :c)) nil) ; (*) + (catch 'foo (throw 'foo (values :x :y))))) + FOO + * (foo) + (:X :Y) -DEFUNCT CATEGORIES OF BUGS - IR1-#: - These labels were used for bugs related to the old IR1 interpreter. - The # values reached 6 before the category was closed down. + Operator THROW is represented with a call of a not returning funny + function %THROW, unknown values stack after the call is empty, so + the unknown values LVAR (*) is considered to be dead after the call + and, thus, before it and is popped by the stack analysis.