Opened 4 years ago

Closed 4 years ago

#1406 closed defect (moved)

REPLACE broken for at least (COMPLEX DOUBLE-FLOAT)

Reported by: tarballs_are_good Owned by:
Priority: normal Milestone:
Component: Compiler Version: trunk
Keywords: Cc:

Description

CL-USER> (let ((a (make-array 4 :element-type '(complex double-float)))
               (b (make-array 4 :element-type '(complex double-float))))
           (dotimes (i 4)
             (setf (aref b i) (complex (* 1.0d0 i) (* 2.0d0 i))))
           (format t "A: ~A~%" a)
           (format t "B: ~A~%" b)
           (replace a b)
           (format t "A <- B: ~A~%" a)
           nil)
A: #(#C(0.0D0 0.0D0) #C(0.0D0 0.0D0) #C(0.0D0 0.0D0) #C(0.0D0 0.0D0))
B: #(#C(0.0D0 0.0D0) #C(1.0D0 2.0D0) #C(2.0D0 4.0D0) #C(3.0D0 6.0D0))
A <- B: #(#C(0.0D0 0.0D0) #C(1.0D0 2.0D0) #C(2.0D0 4.0D0) #C(3.0D0 0.0D0))

The imagpart of the last element isn't making it though. Not sure if this test case exhausts all of the scenarios of this bug.

Change History (4)

comment:1 Changed 4 years ago by rme

%uvector-replace, which is called by cl:replace, is not correctly accounting for the pad word between the uvector header and the start of the data for the complex double-float object. The code tries to account for it by using target::misc-dfloat-offset, but unfortunately that won't work (since on 64-bit x86, at least, misc-dfloat-offset is the same as misc-data-offset).

If my diagnosis is correct, I think we'll have to define target::misc-complex-dfloat-offset, add a slot for it to the arch::target-arch structure (for all of the backends), and use it in %uvector-replace.

comment:2 Changed 4 years ago by rme

  • Resolution set to duplicate
  • Status changed from new to closed

comment:3 Changed 4 years ago by rme

  • Resolution duplicate deleted
  • Status changed from closed to reopened

comment:4 Changed 4 years ago by rme

  • Resolution set to moved
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.