(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
- string-input streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
- [ Bug was reported as "from character streams", but in 0.8.3.10 we
- get correct behaviour from (WITH-OPEN-FILE (i "/dev/zero") (READ-BYTE i)) ]
-
-
60:
The debugger LIST-LOCATIONS command doesn't work properly.
(How should it work properly?)
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
* '``(FOO ,@',@S)
``(FOO SB-IMPL::BACKQ-COMMA-AT S)
+ 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
prominent SourceForge web/db bug tracking system, which is
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))
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
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.)
+ 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.
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)
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
+
+ (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)
+
+ 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.