Custom Query (1030 matches)

r16767 causes trouble on my Raspberry Pi 3.

Linux kupo 4.4.13-v7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux

It reliably fails when doing (rebuild-ccl :clean t) with the following strange error.

;Compiling "/home/rme/ccl/compiler/nxenv.lisp"...
> Error: The value -1069547520 is not of the expected type INTEGER.
> While executing: ARM::ENCODE-ARM-IMMEDIATE, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 > b
*(76BAFE20) : 0 (ENCODE-ARM-IMMEDIATE ???) 40
*(76BAFE20) : 1 (FUNCALL #'#<ARM2-FIXNUM> #<VINSN-LIST #x14557786> #<LREG 8 GPR {5}/LISP> 2 -267386880) 580
 (76BAFE20) : 2 (ARM2-FORM #<VINSN-LIST #x14557786> #<LREG 8 GPR {5}/LISP> 2 #<ACODE fixnum (-267386880)>) 788
 (76BAFE30) : 3 (FUNCALL #'#<ARM2-IF> #<VINSN-LIST #x14557786> #<LREG 8 GPR {5}/LISP> 2 #<ACODE call (#<# # #> # NIL)> #<ACODE fixnum (-267386880)> #<ACODE fixnum (-268435456)>) 2100
 (76BAFEE0) : 4 (ARM2-FORM #<VINSN-LIST #x14557786> #<LREG 8 GPR {5}/LISP> 2 #<ACODE if (#<# # #> #<# # #> #<# # #>)>) 788
...

To duplicate, svn up -r 16766 and bootstrap.

Then, svn up -r 16767, and rebuild the lisp kernel. (rebuild-ccl :clean t) will fail as above.

Building the lisp compiler with -O0 shows the same results as with -O2.

[From Gilbert Baumann]

I found a bug with coercion of RATIOs to SINGLE-FLOATs, like:

(coerce (- (/ (1+ (expt 2 278)) (expt 2 265))) 'short-float) => 8192.0

Which has the wrong sign. This only happens with the 64 bit version and not with the 32 bit version. I consider that a pretty serious bug.

Here is the patch, it fixes %SHORT-FLOAT-RATIO.

*** l0-float.lisp	Sat Sep 24 00:12:44 2016
--- l0-float-fixed.lisp	Sat Sep 24 00:13:43 2016
***************
*** 528,534 ****
                 (make-short-float-from-fixnums 
                    (ldb (byte IEEE-single-float-digits  (- intlen  IEEE-single-float-digits)) int)
                    new-exp
!                    (if minusp 1 0)))
               ; den > num - exp negative
               (progn  
                 (float-rat-neg-exp num den (if minusp -1 1) nil t)))))))))
--- 528,534 ----
                 (make-short-float-from-fixnums 
                    (ldb (byte IEEE-single-float-digits  (- intlen  IEEE-single-float-digits)) int)
                    new-exp
!                    (if minusp -1 1)))
               ; den > num - exp negative
               (progn  
                 (float-rat-neg-exp num den (if minusp -1 1) nil t)))))))))

    (defparameter *rnd-state* (make-random-state t))

    (dotimes (i 300000)
      (let* ((rand-val (random #.(1- (expt 2 64)) *rnd-state*))
             (read-val (read-from-string (with-output-to-string (o)
                                           (pprint rand-val o)))))
        (assert (= rand-val read-val)
                nil
                "rand-val: ~S, read-val: ~S" rand-val read-val)))

At some point (it may be necessary to try a few times), the assert fails and the message is:

    rand-val: 1037244565857250958, read-val: 1037244565857250958

Inspecting the variables in SLIME debuggers shows this:

#<(INTEGER 536870912) #xE65086FE5202E8E>
--------------------
Value: 1037244565857250958 = #xE65086FE5202E8E = #o71450206774510027216 = #b1110 01100101 00001000 01101111 11100101 00100000 00101110 10001110 = 1.0260616E+19
Integer-length: 64



READ-VAL:

#<(INTEGER 536870912) #xE65086FE5202E8E>
--------------------
Value: 1037244565857250958 = #xE65086FE5202E8E = #o71450206774510027216 = #b1110 01100101 00001000 01101111 11100101 00100000 00101110 10001110 = 1.0372446E+18
Integer-length: 60

I (rme) was able to duplicate this on a 32-bit ARM lisp (I haven't tested an x8632 lisp), where the message was

> Error: rand-val: 1769403817437272421, read-val: 1769403817437272421
1 > :f 0
 (76BA44C8) : 0 (%ASSERTION-FAILURE NIL (= RAND-VAL READ-VAL) "rand-val: ~S, read-val: ~S" 1769403817437272421 1769403817437272421) 452
  (SETF-PLACES-P TEST-FORM STRING &REST CONDITION-ARGS)
   SETF-PLACES-P: NIL
   TEST-FORM: (= RAND-VAL READ-VAL)
   STRING: "rand-val: ~S, read-val: ~S"
   CONDITION-ARGS: (1769403817437272421 1769403817437272421)
1 > :arg 'condition-args 0
(1769403817437272421 1769403817437272421)
1 > (mapcar 'integer-length *)
(64 61)
1 > (mapcar 'uvsize **)
(3 2)

So, that's not right: the first value appears to be a three-digit bignum.

This makes me think that we are somehow allowing non-normalized bignums to escape from the lab. I wonder if there's an error in the guts of the implementation of cl:random.

​https://lists.clozure.com/pipermail/openmcl-devel/2017-January/011456.html