X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=0185dc7b54886104afc4ca0773fa02a723435343;hb=44dbdff97fbcc1e5b12e1330da92c5a3dcb94a3b;hp=13c5cc4375db7eefa350ec5da3161d7b835cb7d6;hpb=5822b60341dea34bca191bedbbdd94adef6dc534;p=sbcl.git diff --git a/BUGS b/BUGS index 13c5cc4..0185dc7 100644 --- a/BUGS +++ b/BUGS @@ -464,12 +464,6 @@ 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) - 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately prominent SourceForge web/db bug tracking system, which is @@ -501,17 +495,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 @@ -763,20 +747,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 @@ -1102,8 +1072,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 @@ -1181,16 +1150,6 @@ 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: - - (foo (aref (the (array (unsigned-byte 32)) x))) - 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 @@ -1204,31 +1163,6 @@ 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 @@ -1246,3 +1180,61 @@ WORKAROUND: 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. + +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. + +295: + From Paul Dietz: + + (ash -1000000000000 -10000000000000000000) ==> 0 ;; should be -1 + +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.