dynamic-extent propagation failure make-array/make-struct/list

Bug #586105 reported by James Y Knight
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Fix Released
Medium
Unassigned

Bug Description

For some reason, dynamic extent fails to be propgated through the make-array/make-struct to the list call in the following example program. I don't know why, though. Rather irritating, because it doesn't even print a couldn't d-x allocate compiler note when this happens...

compile-file/load/running testit on the following code prints something like:

array: 2AAAAD8C17FF struct1: 2AAAAD8C1831 struct2: 2AAAAD8C1811
struct1-a: 2AAAAD8C1857 struct2-a: 100334B657

That is: everything got DX-allocated except "(list 6)".
The make-array was dx-allocated, both make-foo were dx-allocated.
The (list 5)" allocated as part of "s" is dx-allocated.
But *not* the (list 6) through make-foo through make-array.

All the cruft in that example isn't necessary, btw, the failure happens just the same way with a "trivial-example", as below. I just added the cruft to attempt to figure out where the problem was occurring.

(declaim (optimize (safety 0) (speed 3) (debug 0)))

(declaim (inline make-foo))
(defstruct foo
  a)

(defun testit ()
  (let* ((s (make-foo :a (list 5)))
         (result (make-array 2 :initial-contents (list s (make-foo :a (list 6))))))
    (declare (dynamic-extent s result))
    (locally (declare (optimize (speed 1)))
      (format t "array: ~X struct1: ~X struct2: ~X struct1-a: ~X struct2-a: ~X"
              (sb-kernel:get-lisp-obj-address result)
              (sb-kernel:get-lisp-obj-address (elt result 0))
              (sb-kernel:get-lisp-obj-address (elt result 1))
              (sb-kernel:get-lisp-obj-address (foo-a (elt result 0)))
              (sb-kernel:get-lisp-obj-address (foo-a (elt result 1)))))))

(defun trivial-example ()
  (let ((result (make-array 1 :initial-contents (list (make-foo :a (list 6))))))
    (declare (dynamic-extent result))
    (car (foo-a (elt result 0)))))

Tested with SBCL 1.0.38.12 Linux x86-64.

Changed in sbcl:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Nikodemus Siivola (nikodemus) wrote :

The problem lies in the array optimizations making LIST NOTINLINE in order to pick it apart -- which foils DX for it later on.

Revision history for this message
Nikodemus Siivola (nikodemus) wrote :

Apropos: when trying to figure out how something is decided to be DX or not, a good strategy is to put a break after HANDLE-NESTED-DYNAMIC-EXTENT-LVARS in RECHECK-DYNAMIC-EXTENT-LVARS, and trace H-N-D-E-L and its callees.

Changed in sbcl:
assignee: nobody → Nikodemus Siivola (nikodemus)
status: Triaged → In Progress
Revision history for this message
Nikodemus Siivola (nikodemus) wrote :

In SBCL 1.0.42.12.

Changed in sbcl:
assignee: Nikodemus Siivola (nikodemus) → nobody
status: In Progress → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.