Running a cn.sum reduction over a sliced store inside an inline PyTask aborts with a reduction
accessor assertion. The same code path is fine in normal (non-inline) execution. It looks like the
reduction accessor built for an inline-mapped store ends up with an accessor kind/layout that the
reduction path does not accept.
This affects at least lstm_backward.py example with cn.sum(dHin[t, :, word_size:], 0) aborts with a reduction-accessor assertion:
accessors.inl:5007 ... Assertion 'false && "Incompatible accessor"'
Running a
cn.sumreduction over a sliced store inside an inline PyTask aborts with a reductionaccessor assertion. The same code path is fine in normal (non-inline) execution. It looks like the
reduction accessor built for an inline-mapped store ends up with an accessor kind/layout that the
reduction path does not accept.
This affects at least
lstm_backward.pyexample withcn.sum(dHin[t, :, word_size:], 0)aborts with a reduction-accessor assertion: