IntelPython / dpnp / 34346092133

79%

push

github

Fix row corruption in batched multi-level cumulative scan (#3063)

## Summary

`dpnp.cumsum`, `dpnp.cumprod`, and their `nan`/`cumulative_*` variants
(including `dpnp.tensor.cumulative_sum`/`cumulative_prod`) could
silently return incorrect results when accumulating along an axis of a
multi-row array, with no error raised. The corruption is triggered when
the accumulation axis is long enough to require three or more reduction
levels in the internal block-scan (axis length greater than `chunk_size
** 2`, where `chunk_size = wg_size * n_wi`, i.e. roughly a million
elements on GPU and about four million on CPU) and the array has more
than one batch row. The elementwise total is conserved but redistributed
across rows.

## Root cause

In the batched scan driver `inclusive_scan_iter` (`accumulators.hpp`),
the intermediate block-scan fixup `update_local_chunks` passed a
`NoOpIndexer` for the per-row (iter) offset into the `src` buffer. The
intermediate block-scan buffers, however, are laid out strided per row
with a stride of `src_size`. The `local_scans` read already used the
correct `iter_gid * local_stride` offset, but the `src` write offset was
unstrided, so rows overwrote each other. This cancels out only when
`iter_nelems == 1` (a single row) or when fewer than three levels are
needed, which is why the bug went unnoticed.

## Fix

Give `update_local_chunks` a `Strided1DIndexer{iter_nelems, src_size}`
for the row offset instead of the `NoOpIndexer` (the within-row
`out_indexer` stays `NoOp`, since the level buffers are contiguous
within a row).

1546 of 2894 branches covered (53.42%)

Branch coverage included in aggregate %.

26632 of 33004 relevant lines covered (80.69%)

8616.1 hits per line