[CuTeDSL] Fix export_to_c shape slot width for 64-bit dynamic dims

[wilyan09007]

Summary

_generate_arguments derives a tensor descriptor's stride type from the tensor but passes shape_type="int32_t" unconditionally, so cute.sym_int64() dimensions get int32_t shape slots while the compiled function reads them as i64. A C caller filling in that struct hands over a descriptor half the expected size.

The widths are already known one layer down: _tensor_binding keeps a SymInt dimension at its declared width and gives every other dynamic dimension 32 bits. This derives the shape type the same way at both call sites. One array cannot hold dimensions of two widths, so a tensor mixing them is refused, and the list/tuple descriptor check now compares width alongside the masks it already had.

Verification

Added test/python/CuTeDSL/test_export_c_header_shape_type.py, 8 tests. Four fail on main: the sym_int64 slot width, the mixed-width rejection, and both tensor-list cases. The sym_int32, static-shape, and DLPack-dynamic cases pass before and after.

Fixes #3447

[anakinxc]

LGTM

[Observer007]

LGTM

[Observer007]

Just curious, in what real cases do we need i64 shape representation?

[wilyan09007]

A genuinely 64-bit extent shows up on a flat 1-D view over a whole buffer: red.py and reduction/block_smem_reduce.py both declare (cute.sym_int64(),), and 2^31 elements is 2 GB of fp8. For GEMM M/N/K it is rare.

The corruption doesn't need a large value though. Shape and stride slots share one descriptor struct, so int32 shapes against an i64 ABI both narrow the shape read and shift the strides. M=128 breaks the same way a 3e9 dim would.