Custom Query (1030 matches)

The following test case fails:

(defconstant ZERO #C(0.0d0 0.0d0))
(defconstant ONE #C(1.0d0 0.0d0))

(defun bug ()
  (LET ((RESULT (MAKE-ARRAY 2 :ELEMENT-TYPE '(COMPLEX DOUBLE-FLOAT)
                              :INITIAL-ELEMENT ZERO)))
    (DECLARE (TYPE (SIMPLE-ARRAY (COMPLEX DOUBLE-FLOAT) (2)) RESULT))
    (SETF (AREF RESULT 0) ONE)
    (FORMAT T "~&Set 0th to 1: ~A~%" RESULT)
    (SETF (AREF RESULT 1) ONE)
    (FORMAT T "~&Set 1st to 1: ~A~%" RESULT)
    RESULT))

It looks like the second SETF isn't SETFing far enough into whatever underlying representing. I get

> (bug)
Set 0th to 1: #(#C(1.0D0 0.0D0) #C(0.0D0 0.0D0))
Set 1st to 0: #(#C(0.0D0 5.299808824D-315) #C(0.0D0 0.0D0))
#(#C(0.0D0 5.299808824D-315) #C(0.0D0 0.0D0))

which indicates the second SETF isn't getting far enough.

When passing less values than variables to destructure against CCL raises a SIMPLE-PROGRAM-ERROR

(loop :with (a b) := '(nil))
;; =>
(NIL) can't be destructured against the lambda list (A
                                                     B
                                                     . #:LOOPVAR-8347), because it does not contain at least 2 elements.

The CLHS says that b should be given a value of nil in this case.

During loop expansion, each variable in the variable list is matched with the values in the values list. If there are more variables in the variable list than there are values in the values list, the remaining variables are given a value of nil

​6.1.1.7 Destructuring

SBCL which shares the same loop implementation of CCL handled this bug in ​this way.

It seems very surprising to get a segmentation fault with safety 3. Below are instructions from the README file of the attached gzipped tarfile, which show how to re-create that behavior. This example is a lightly modified version of a real problem we are having, where we cannot debug the problem because of the segmentation fault. Note: We did this on linux:

dunnottar:~% uname -a Linux dunnottar 3.13.0-110-generic #157-Ubuntu SMP Mon Feb 20 11:54:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux dunnottar:~%

But we have seen this problem on Mac as well.

Note: We have reproduced this bug using this CCL

Welcome to Clozure Common Lisp Version 1.12-dev-r16783M-trunk (LinuxX8664)!

but also ones as recent as last weekend.

.....

wget https://github.com/acl2-devel/acl2-devel/releases/download/7.3/acl2-7.3.tar.gz
tar xfz acl2-7.3.tar.gz
# Save disk space
rm -rf acl2-7.3/books
rm acl2-7.3.tar.gz
cd acl2-7.3
(time nice make LISP=ccl ACL2_SAFETY=3) >& make-safety-3.log
cd ..
./acl2-7.3/saved_acl2
(value :q)
(load "clrat-parser.lisp")
(clrat-read-file "R_4_4_18.clrat" state)