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
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.
+
+291: "bugs in deletion of embedded functions"
+
+ Python fails to compile (simplified version of the problem reported
+ by Nikodemus Siivola)
+
+ (defstruct (line)
+ (%chars ""))
+
+ (defun update-window-imag (line)
+ (tagbody
+ TOP
+ (if (null line)
+ (go DONE)
+ (go TOP))
+ DONE
+ (unless (eq current the-sentinel)
+ (let* ((cc (car current))
+ (old-line (dis-line-line cc)))
+ (if (eq old-line line)
+ (do ((chars (line-%chars line) nil)) ; <LET>
+ (())
+ (let* ()
+ (multiple-value-call
+ #'(lambda (&optional g2740 g2741 &rest g2742)
+ (declare (ignore g2742))
+ (catch 'foo ; <CLEANUP>
+ (values (setq string g2740) (setq underhang g2741))))
+ (foo)))
+ (setf (dis-line-old-chars cc) chars)))))))
+
+ Compiler deletes unreachable BIND node of <LET>, but its body,
+ including reference to the variable CHARS, remains reachable through
+ NLX from <CLEANUP>.
projects / sbcl.git / blobdiff