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
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
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.