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
(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
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:
(taken from CLOCC)
-277:
- IGNORE/IGNORABLE declarations should be acceptable for symbol
- macros.
-
278:
a.
(defun foo ()
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
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
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.
+
+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.
projects / sbcl.git / blobdiff