Compiler problem with new words/63bit fixnums

[Martin Cracauer]

There is a brokenness about atomic-incf in arrays of words introduced by Alastair with the recent interger/fixnum changes. Sorry for missing the release with this report.

The code below will do the atomic-incf to both the wrong location and with the wrong value.

Compiling the code (more) might be necessary to reproduce. I have the interpreter off.

(sb-ext:defglobal *bytes-consed-log-array*
    (make-array 42 :initial-element 0 :element-type 'sb-ext:word))
(declaim (type (vector sb-ext:word 42) *bytes-consed-log-array*))

(defun log-values (index bytes-consed)
  (declare (type (signed-byte 64) bytes-consed))
  (print *bytes-consed-log-array*)
  (atomic-incf (aref *bytes-consed-log-array* index) bytes-consed)
  (print *bytes-consed-log-array*)
  nil)

(compile 'log-values)

(defun testme ()
  (log-values 3 42))

(testme)

==>

old SBCL:

:cl-user 160 K Yes, Master?
#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 0 0)
#(0 0 0 42 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 0 0 0)
NIL

SBCL after integer changes:

:cl-user 159 K Yes, Master?
#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 0 0)
#(11821949021847552 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 0 0 0 0 0 0 0 0 0 0)
NIL

[Paul Khuong (pvk)]

Thanks for the report! Fixed in 6b0e405: Correct address computation in atomic-incf/aref for wide fixnums .