PyTorch Inductor corrupts heap on dynamic-shape index_fill path
A fill-order versus stride-order mixup in copy_strided lowering overruns CPU buffers under torch.compile with dynamic shapes.
PyTorch's Inductor compiler can abort with heap corruption on CPU when torch.compile is used with dynamic shapes on a graph that does index_fill and then a reduction.
The index_fill path copies its result back onto the input's strides via copy_strided. Inductor's lowering for that op builds an order by sorting strides and passes it to a helper that expects the inverse: the stride order, not the fill order. Those agree for self-inverse layouts such as a plain 2-d transpose, which is why many cases look fine. On other layouts, including common transposed tensors, the generated buffer ends up with the wrong shape. With dynamic shapes the C++ reduction then performs an unmasked vector store past the end of that buffer, producing double-free and malloc corruption messages that vary by size and run.
Static shapes are unaffected. The failure reproduces on 2.14 and recent nightlies. Substituting the existing stride-order helper for the sort fixes the reported cases; the bad layout is also what exposed the unmasked tail store.