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