FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

api: materialise a strided view before assigning into it by melonakos · Pull Request #3729 · arrayfire/arrayfire · GitHub

Repository navigation

api: materialise a strided view before assigning into it - #3729

Draft
melonakos wants to merge 1 commit into
masterfrom
fix/3534-assign-into-view
Draft

melonakos wants to merge 1 commit into
masterfrom
fix/3534-assign-into-view

Conversation

Copy link
Copy Markdown
Member

Assigning an element into an array that is itself a non-linear view silently did nothing on every backend: after a = a.rows(0, 3), a(0, 0) = 1234 leaves a unchanged (#3534). The sequence-assignment path slices the output with createSubArray, which copies a non-linear parent before slicing it, so the write landed in a temporary. When the output is not linear it is now copied to a linear array first, the same thing that already happens when the output is shared. Adds a regression test covering sequence and index-array assignment into a view.

Verified on the CPU backend and on OpenCL (Intel Arc B580 and UHD 770): the new test fails on master and passes with the fix, and the assign suite passes in full on all three.

An array that is itself a non-linear view (a = a.rows(0, 3)) lost every
element assignment: createSubArray copies a non-linear parent before slicing
it, so the write landed in a temporary. The assignment path now copies such an
output to a linear array first. Fixes #3534.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant


Back | FazBrowse Home | New Git URL