Development of Steel Bank Common Lisp

Eric Marsden | 23 May 2012 14:01

BUG: incorrect results from LOGAND (AMD64)

Hi,

* (lisp-implementation-version)
"1.0.57.15-35f68f4"
* (defun foo (x)
    (declare (optimize (space 2))
             (type (integer 12417236377505266230 12417274239874990070) x))
    (logand 8459622733968096971 x))
FOO
* (foo 12417237222845306758)
11836165733894624898  ;; <-- incorrect
* (logand 8459622733968096971 12417237222845306758)
2612793697039849090
* (defun bar (x) 
    (declare (type (integer 22965360520649903105 22965361070405717069) x))
    (lognand 6936474818856893141 x))
BAR
* (bar 22965361070405716988)
#<unknown immediate object, lowtag=#b1, widetag=#x41 {FFFFFFEFFD4D3D41}>

(More random-integer testing.)

--

-- 
Eric Marsden

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware

(Continue reading)

headers

Christophe Rhodes | 23 May 2012 17:06

Re: BUG: incorrect results from LOGAND (AMD64)

Eric Marsden <eric.marsden <at> free.fr> writes:

> * (lisp-implementation-version)
> "1.0.57.15-35f68f4"
> * (defun foo (x)
>     (declare (optimize (space 2))
>              (type (integer 12417236377505266230 12417274239874990070) x))
>     (logand 8459622733968096971 x))
> FOO
> * (foo 12417237222845306758)
> 11836165733894624898  ;; <-- incorrect
> * (logand 8459622733968096971 12417237222845306758)
> 2612793697039849090
> * (defun bar (x) 
>     (declare (type (integer 22965360520649903105 22965361070405717069) x))
>     (lognand 6936474818856893141 x))
> BAR
> * (bar 22965361070405716988)
> #<unknown immediate object, lowtag=#b1, widetag=#x41 {FFFFFFEFFD4D3D41}>
>
> (More random-integer testing.)

I think what is happening here is more of the same as last month.  When
cleverly deriving that the arithmetic operations mean that some of the
bits in bignums will not affect the answer, and hence that the operation
can be performed with fewer bits (and signed arithmetic), it is
important that all the operands be converted -- otherwise a high bit in
one operand will be in the same place as the infinite sequence of sign
bits in the other, and the wrong answer will ensue.  In FOO, above, the
combination should be changed to

(Continue reading)