- cmucl-ticket - mailman3.common-lisp.net

[cmucl-ticket] #21: Modular arith bug 3
by cmucl 21 Aug '08

21 Aug '08

#21: Modular arith bug 3 --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 2008-08 Keywords: | --------------------+------------------------------------------------------- The following code doesn't use modular arithmetic for ash: {{{ (defun bug (v) (declare (type (unsigned-byte 32) v) (optimize (speed 3) (safety 0))) (logand #xffffffff (logxor v (ash v (- -16))))) }}} You get compiler warnings about {{{ASH}}}. But the equivalent code is ok: {{{ (defun bug-a (v) (declare (type (unsigned-byte 32) v) (optimize (speed 3) (safety 0))) (ldb (byte 32 0) (logxor v (ash v (- -16))))) }}} Also, if in {{{bug}}}, you change {{{(- -16)}}} to the obvious {{{16}}}, the compiler notes are gone, and the generated code is as expected. What appears to be happening is that when {{{logand-defopt-helper}}} is run, the compiler doesn't know the type of the shift for {{{ASH}}}. Hence, it can't do modular arithmetic stuff. However, when the code is finally generated, you can see that the shift is now a known constant value of 16. I don't know why. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/21> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] #17: LOOP NAMED NIL has no effect
by cmucl 14 Jul '08

14 Jul '08

#17: LOOP NAMED NIL has no effect ----------------------+----------------------------------------------------- Reporter: sionescu | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 19e Keywords: | ----------------------+----------------------------------------------------- HU> (macroexpand '(loop named nil)) (TAGBODY ANSI-LOOP::NEXT-LOOP (GO ANSI-LOOP::NEXT-LOOP) ANSI-LOOP::END- LOOP) T I'm using snapshot 2008-07 -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/17> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] #16: Read-time hash-table issue
by cmucl 07 May '08

07 May '08

#16: Read-time hash-table issue ----------------------+----------------------------------------------------- Reporter: sionescu | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 19d Keywords: | ----------------------+----------------------------------------------------- LOADing a fasl produced when compiling a file that contains just (cl:defparameter *ht* #.(cl:make-hash-table)) yields this error: Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable LISP::TABLE is unbound. [Condition of type UNBOUND-VARIABLE] Backtrace: 0: ("Creation Form for #<HASH-TABLE :TEST EQL :WEAK-P NIL :COUNT 0 {58F5A68D}>")[:TOP-LEVEL] 1: (LISP::FOP-FUNCALL) 2: (LISP::LOAD-GROUP #<Stream for file "/home/hechee/tmp/a.x86f">) 3: (LISP::FASLOAD #<Stream for file "/home/hechee/tmp/a.x86f">) 4: (LISP::INTERNAL-LOAD #P"/home/hechee/tmp/a.x86f" #P"/home/hechee/tmp/a.x86f" :ERROR :BINARY) 5: (LISP::INTERNAL-LOAD #P"/home/hechee/tmp/a.x86f" #P"/home/hechee/tmp/a.x86f" :ERROR NIL) 6: (LOAD #P"/home/hechee/tmp/a.x86f" :VERBOSE NIL :PRINT ...) The error is reproducible on 19d and 19e-pre2 -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/16> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 4

[cmucl-ticket] #15: x86 double-float issue
by cmucl 11 Apr '08

11 Apr '08

#15: x86 double-float issue --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19d Keywords: | --------------------+------------------------------------------------------- Consider this sample code {{{ (defun rbug (z tt betain beta) (declare (double-float z tt betain beta) (optimize (speed 3) (safety 0))) (= (* (* (* z tt) betain) beta) z)) }}} Compile it and run: {{{ (rbug 5.562684646268004d-309 (1+ double-float-epsilon) .5d0 2d0) }}} This is t on sparc, nil on x86. This is caused by x86 issues with double-float (53-bit) precision and the extra range of the exponent in long-double (64-bit) format. Denormals in this format are not handled the same as denormals on sparc or ppc. There is a fix for this. When computing x*y, we scale x by an appropriate value, multiply by y, and scale back. This will produce the correctly rounded denormal. The only issue would be the exponent range. That is fixed by storing the number to memory and reloaded. (This solution taken from a proposed solution for Java numerics). This could be easily implemented, but potentially slows down double-float arithmetic by a factor of 2-4 times. I don't think we want to do that. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/15> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 0

[cmucl-ticket] #14: cmucl.css
by cmucl 11 Apr '08

11 Apr '08

#14: cmucl.css ---------------------+------------------------------------------------------ Reporter: heller | Owner: somebody Type: defect | Status: new Priority: trivial | Milestone: Component: Core | Version: 19d Keywords: | ---------------------+------------------------------------------------------ many of the HTML files in cmu-user-html.tgz link to the cmucl.css stylesheet, but it's not in the tarball. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/14> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 2

[cmucl-ticket] #13: (format nil "~11, 3, 2, 0, '*, , 'EE" .9999) -> " 1.000E+00"
by cmucl 27 Feb '08

27 Feb '08

#13: (format nil "~11,3,2,0,'*,,'EE" .9999) -> " 1.000E+00" --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19d Keywords: | --------------------+------------------------------------------------------- I think the given format should produce 0.100E+1 instead, because the scale factor is 0. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/13> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] #12: (format t "~10,1,2,0,'*,,'DE" 1d-6) -> 1.0d-6
by cmucl 09 Oct '07

09 Oct '07

#12: (format t "~10,1,2,0,'*,,'DE" 1d-6) -> 1.0d-6 --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19d Keywords: | --------------------+------------------------------------------------------- {{{ (format t "~10,1,2,0,'*,,'DE" 1d-6) -> 1.0D-06 }}} But since the scale factor is 0, the digits should be printed after the decimal point. The CLHS, sec 22.3.3.2 says: {{{ If k is zero, then d digits are printed after the decimal point, and a single zero digit appears before the decimal point if the total field width will permit it. }}} This works ok for other values: {{{ (format t "~10,1,2,0,'*,,'DE" 1d-5) -> 0.1D-04 }}} -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/12> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 2

[cmucl-ticket] [cmucl] #1: prin1 and ~E produce different outputs.
by cmucl 03 Oct '07

03 Oct '07

#1: prin1 and ~E produce different outputs. ------------------------+--------------------------------------------------- Reporter: anonymous | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: component1 | Version: Keywords: printing | ------------------------+--------------------------------------------------- (let ((x (random 1d-3))) (values (prin1-to-string x) (format nil "~E" x))) will produce different significant digits. I think the problem is in ~E which calls lisp::scale-exponent to scale the number between 0.1 and 1. I think we could just call flonum-to-digits which will give us the digits and the exponent. We can massage that into the desired digits and exponent as in scale-exponent, but we won't have the round-off problem. Maybe. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/1> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 4

[cmucl-ticket] #11: (eql 0w0 0w0) is NIL, but should be T.
by cmucl 28 Aug '07

28 Aug '07

#11: (eql 0w0 0w0) is NIL, but should be T. --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: Core | Version: 19d Keywords: | --------------------+------------------------------------------------------- (eql 0w0 0w0) is NIL but it should be T, just like (eql 0d0 0d0) is T. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/11> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] #10: round is sometimes wrong for numbers bigger than most-positive-fixnum
by cmucl 19 May '07

19 May '07

#10: round is sometimes wrong for numbers bigger than most-positive-fixnum --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19d Keywords: round | --------------------+------------------------------------------------------- {{{(round (+ 536870911 1.5d0))}}} should return 536870912 and 0.5d0. However, cmucl returns 536870913 and -0.5d0. The code in float.lisp for {{{%unary-round}}} appears to be wrong for numbers outside fixnum range. At the very least we should extend the range to {{{(signed-byte 32)}}}, but there would still be issues for other numbers. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/10> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1