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
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").
+ 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.
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
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)
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:
(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:
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
(foo (aref (the (array (unsigned-byte 32)) x)))
-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.
+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.