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
cuTile Python version
1.5.0. The same reproducer also fails with 1.4.0.
CUDA Toolkit version
13.3 (
tileirasV13.3.36)Which installation method does this occur on?
Pip
Describe the bug
tileirasterminates withSIGSEGVwhile compiling a kernel that reads onetensor through
get_raw_memory().load_offset, stages those vectors, and laterloads 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. Thereproducer below needs only two panel iterations, two vectors per panel, and a
float32[1,512,64]matrix.Minimum reproducible example
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.
Relevant log output
Running the emitted compiler input directly is deterministic:
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
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:
256x32 passes;
consumer passes;
That suggests the failure is in the combined lowering rather than memory capacity,
the launch grid, or runtime input data.
Contributing Guidelines