#21: Modular arith bug 3
---------------------+------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: Core | Version: 2008-08
Resolution: | Keywords:
---------------------+------------------------------------------------------
Comment(by rtoy):
This should be fixed in the 2008-12 snapshot.
We now delay {{{logand-defopt-helper}}}until after {{{IR2}}} optimizations
are done so that we give the compiler a chance to derive all of the
variable types. Then we run this optimizer. This will cause some
increase in compilation time for code that deals with modular arithmetic,
but we should get better behaved modular arithmetic.
--
Ticket URL: <http://127.0.0.1:8000/cmucl/ticket/21#comment:2>
cmucl <http://common-lisp.net/project/cmucl>
cmucl
#15: x86 double-float issue
---------------------+------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: Core | Version: 19d
Resolution: | Keywords:
---------------------+------------------------------------------------------
Comment(by rtoy):
This should be fixed in the 2008-12 snapshot when sse2 is used. This
issue will remain for x87; we have no intention of fixing this.
--
Ticket URL: <http://127.0.0.1:8000/cmucl/ticket/15#comment:1>
cmucl <http://common-lisp.net/project/cmucl>
cmucl
#23: [cmucl-help] Spurious compilation diagnostic?
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: Core | Version: 2008-09
Keywords: |
--------------------+-------------------------------------------------------
Reported on cmucl-help, by Steven Edwards, 2008/09/21.
{{{
(defun read-ch (my-stream)
(declare (optimize speed (space 0)))
(read-char my-stream nil nil))
}}}
produces spurious warnings:
{{{
; In: DEFUN READ-CH
; (READ-CHAR MY-STREAM NIL NIL)
; --> BLOCK LET LISP::STREAM-DISPATCH ETYPECASE LET COND IF COND IF PROGN
; ==>
; (STREAM::%READ-CHAR STREAM LISP::EOF-ERRORP LISP::EOF-VALUE
; LISP::RECURSIVE-P ...)
; Warning: Undefined function STREAM::%READ-CHAR
;
; --> BLOCK LET LISP::STREAM-DISPATCH ETYPECASE LET COND IF COND IF COND
; --> IF PROGN LET
; ==>
; (STREAM-READ-CHAR STREAM)
; Warning: Undefined function STREAM-READ-CHAR
; ;
; Warning: These functions are undefined:
; STREAM::%READ-CHAR STREAM-READ-CHAR
;
}}}
These are caused by the stream-dispatch mechanism and the functions aren't
defined because Gray streams and simple-streams aren't loaded.
We should probably get rid of the warnings.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/23>
cmucl <http://common-lisp.net/project/cmucl>
cmucl
#22: sun4_solaris_sunc config uses gcc to build motif
---------------------+------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: trivial | Milestone:
Component: Core | Version: 2008-09
Keywords: |
---------------------+------------------------------------------------------
The sun4_solaris_sunc config to use Sun C to compile the lisp code. That
works fine. But the motif config uses gcc to build the motif code. This
is ok, but perhaps there should be a config that uses Sun C.
Pretty minor issue, I think. It just means you need both Sun C and gcc,
which is standard with Solaris 10 these days.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/22>
cmucl <http://common-lisp.net/project/cmucl>
cmucl
#20: Modular arith bug?
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 19e
Keywords: |
--------------------+-------------------------------------------------------
{{{
(defun mat3neg (tt v)
(ldb (byte 32 0) (ash v (- tt))))
(defun mat3neg-a (tt v)
(logand #xffffffff (ash v (- tt))))
(defun zot (z2)
(declare (type (unsigned-byte 32) z2)
(optimize speed (safety 0)))
(mat3neg -28 z2))
(defun zot-a (z2)
(declare (type (unsigned-byte 32) z2)
(optimize speed (safety 0)))
(mat3neg-a -28 z2))
}}}
Compile {{{zot}}} and there are lots of compiler notes, from
{{{mat3neg}}}. But compile {{{zot-a}}} and there's just one for boxing up
the result.
However, {{{zot}}} and {{{zot-a}}} are functionally identical, so
{{{zot}}} and {{{zot-a}}} should produce the same code. But {{{zot}}} has
to do a full call to {{{ash}}} and {{{two-arg-and}}}.
The {{{ldb}}} must be confusing the compiler somehow.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/20>
cmucl <http://common-lisp.net/project/cmucl>
cmucl
#19: Modular arith bug 2
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: Core | Version: 19b
Keywords: |
--------------------+-------------------------------------------------------
This was reported by Martin Cracauer to cmucl-imp, 2005-07-20.
{{{
(defun fixnum-hasher (a)
(declare
(optimize (speed 3) (safety 0) #+nil(debug 1)) ;; BUG HERE, only in
fast mode
(type fixnum a)) ;; bug equally apears if you leave this out
(logand
(the fixnum ;; BUG HERE. Drop this declaration and the bug disappears
(logxor (ash a -20) -482305527))
1023))
}}}
Repeatedly calling {{{(fixnum-hasher 27)}}} returns random values! The
problem is caused by modular arithmetic because if it is turned off (by
{{{setf c::*enable-modular-arithmetic* nil)}}} the bug doesn't happen.
The answer should be 521.
A related bug is
{{{
(defun foo (a b)
(locally (declare (optimize (speed 3) (safety 0) (debug 1)))
(the fixnum
(logand (the fixnum
(logxor (the fixnum a)
(the fixnum b)))
(the fixnum (1- (ash 1 18)))))))
}}}
This bug is mentioned in the same thread, but is from sbcl-devel, 2005-04-
29.
{{{(foo -1234 1234)}}} returns random values. The correct answer is
262140.
In both cases, there is a call to vm::logxor-mod32 with fixnum args,
returning an unsigned 32-bit result. This is not right.
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/19>
cmucl <http://common-lisp.net/project/cmucl>
cmucl
#18: Modular arith bug 1
--------------------+-------------------------------------------------------
Reporter: rtoy | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: Core | Version: 19d
Keywords: |
--------------------+-------------------------------------------------------
Not really a bug, but a deficiency.
{{{
(defun ref (a n)
(declare (type (simple-array single-float (*)) a)
(type (integer 0 15) n)
(optimize (speed 3) (safety 0)))
(aref a (logand #xf (+ n 15))))
}}}
Relevant disassembly on sparc:
{{{
68: SRA %A1, 2, %NL0 ; %A1 = N
; No-arg-parsing
entry point
; [:NON-LOCAL-
ENTRY]
6C: ADD 15, %NL0
70: AND 15, %NL0
74: SLL %NL0, 2, %NL1
78: ADD %NL1, 1, %NL0
7C: LDF [%A0+%NL0], %F0 ; %A0 = A
}}}
So {{{N}}} is converted from a fixnum to an integer, the appropriate
operations are done, and then converted back to a fixnum. All of this
could have been done without the conversion like so:
{{{
40: ADD 60, %A1 ; %A1 = N
; No-arg-parsing
entry point
; [:NON-LOCAL-
ENTRY]
44: AND 60, %A1
48: ADD %A1, 1, %NL0
4C: LDF [%A0+%NL0], %F0 ; %A0 = A
}}}
--
Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/18>
cmucl <http://common-lisp.net/project/cmucl>
cmucl
