[BUG]: tileiras SIGSEGV mixing raw-memory and tiled access in nested reduction loops

cuTile Python version

1.5.0. The same reproducer also fails with 1.4.0.

CUDA Toolkit version

13.3 (tileiras V13.3.36)

Which installation method does this occur on?

Pip

Describe the bug

tileiras terminates with SIGSEGV while compiling a kernel that reads one
tensor through get_raw_memory().load_offset, stages those vectors, and later
loads and stores 512x32 tiles from the same tensor around a reduction. The crash
happens during compilation; no kernel is executed.

I expected this program to compile. If mixing raw and tiled access to one tensor
is unsupported, I expected a source diagnostic explaining that restriction rather
than a native compiler crash.

This was reduced from a blocked QR kernel. The original program used a
float32[batch,512,512] input and failed for both batch 16 and batch 1. The
reproducer below needs only two panel iterations, two vectors per panel, and a
float32[1,512,64] matrix.

Minimum reproducible example

import torch
import cuda.tile as ct


@ct.kernel
def kernel(matrix, vectors):
    memory = matrix.get_raw_memory()
    rows = ct.arange(512, dtype=ct.int32)
    for panel in range(2):
        for j in range(2):
            column = panel * 2 + j
            values = memory.load_offset(rows * 64 + column)
            ct.store(vectors, (0, column, 0), values.reshape((1, 1, 512)))
        for tile in range(panel, 2):
            block = ct.load(matrix, (0, 0, tile), (1, 512, 32))
            for j in range(2):
                vector = ct.load(
                    vectors, (0, panel * 2 + j, 0), (1, 1, 512)
                ).permute((0, 2, 1))
                projection = ct.sum(vector * block, axis=0, keepdims=True)
                block -= vector * projection
            ct.store(matrix, (0, 0, tile), block)


matrix = torch.empty((1, 512, 64), device="cuda")
vectors = torch.empty((1, 4, 512), device="cuda")
ct.launch(torch.cuda.current_stream(), (1,), kernel, (matrix, vectors))

Run with a fresh compiler cache. Crash dumps are disabled here only because the
separate crash-dump problem reported in #92 otherwise masks the primary error.

run=$(mktemp -d)
CUDA_TILE_CACHE_DIR=off \
CUDA_TILE_TEMP_DIR="$run" \
CUDA_TILE_ENABLE_CRASH_DUMP=0 \
python repro.py

Relevant log output

subprocess.CalledProcessError: Command '['/usr/local/cuda/bin/tileiras',
  '/tmp/.../kernel....bytecode', '-o',
  '/tmp/.../kernel....cubin', '--gpu-name', 'sm_120',
  '-O3', '--lineinfo']' died with <Signals.SIGSEGV: 11>.

cuda.tile._exception.TileCompilerExecutionError: Return code -11
Unknown location

Running the emitted compiler input directly is deterministic:

bytecode=$(find "$run" -name 'kernel*.bytecode' -print -quit)
/usr/local/cuda/bin/tileiras "$bytecode" -o kernel.cubin \
  --gpu-name sm_120 -O3 --lineinfo
# Segmentation fault; shell status 139; no cubin is produced

Two independent cold Python runs produced the same failure and direct compiler
status. The failure also persists when the same script imports cuTile Python
1.5.0 instead of 1.4.0.

Environment

OS: Ubuntu 22.04.5 LTS, Linux 6.8.0-90-generic x86_64
GPU: NVIDIA RTX PRO 6000 Blackwell Server Edition, compute capability 12.0
Driver: 580.126.09
CUDA toolkit: 13.3; nvcc 13.3.33; tileiras V13.3.36
Python: 3.13.14
PyTorch: 2.12.0+cu130 (bundled CUDA runtime 13.0)
cuTile Python: 1.5.0; also reproduced on 1.4.0
CPU: AMD EPYC 9355, 16 vCPUs

Other details

The original source failure was in a kernel named _qr512_blocked.
Both halves of the original kernel compile when separated. In the reduced case:

• changing the reduced geometry and associated tensor stride from 512x32 to
  256x32 passes;
• changing that geometry to 512x16 or 512x64 passes;
• keeping raw and tiled access to the same tensor but removing the reduction
  consumer passes;
• removing either the raw-memory producer or the tiled reduction consumer passes.

That suggests the failure is in the combined lowering rather than memory capacity,
the launch grid, or runtime input data.

Contributing Guidelines

• I agree to follow cuTile Python's contributing guidelines
• I searched the open bugs and found no duplicate for this report