Converter aborts (bad_optional_access) on aten.arange with float start/end/step args

[john-rocky]

Summary

TorchConverter.to_coreai() aborts the whole process with a C++ bad_optional_access (no Python exception, -fno-exceptions abort) whenever the exported program contains aten.arange with float start/end/step arguments. Integer arguments work, regardless of the requested output dtype — it is the argument types that matter, not the tensor dtype.

Environment

• coreai-torch 0.4.0, coreai-core 1.0.0b1 (cp312), torch 2.11.0
• macOS 27.0 (build 26A5353q), M4 Max

Minimal repro

import torch
from coreai_torch import TorchConverter, get_decomp_table

class M(torch.nn.Module):
    def forward(self, x):
        return x + torch.arange(8.0, dtype=x.dtype)   # float end -> abort
        # return x + torch.arange(8, dtype=x.dtype)   # int end -> converts fine

ep = torch.export.export(M().eval(), (torch.rand(1, 8),)).run_decompositions(get_decomp_table())
TorchConverter().add_exported_program(exported_program=ep, input_names=["x"], output_names=None).to_coreai()

Output:

coreai-torch 0.4.0: converting 1 program(s) to Core AI
bad_optional_access was thrown in -fno-exceptions mode
[process aborts]

Why it matters in the wild

DETR-family sine position embeddings commonly call gen_sineembed_for_position(..., d_model / 2) — the Python division produces a float dim, so torch.arange(128.0) lands in the graph and the conversion dies with no actionable message. Hit while porting RF-DETR (roboflow/rf-detr 1.7.1).

Expected

Either lower float-arg arange (the values here are static constants) or fail validation with a clear unsupported-op message like other unsupported ATen ops do (e.g. aten.remainder.Scalar reports cleanly at add_exported_program time).

Workaround

Precompute the vector in Python (e.g. torch.tensor([10000.0 ** (2 * (i // 2) / dim) for i in range(dim)])) so the graph sees a single constant.