[voltjia]

NineToothed represents floating-point scalar arguments as fp64 in shared Triton AOT signatures. RMSNorm added that scalar directly to an FP32 accumulator before calling sqrt, so Ascend Triton rejected the operation because its sqrt does not accept fp64.

Cast epsilon to FP32 before adding it to the FP32 accumulator. This preserves the public scalar ABI while keeping the square-root input in the accumulator dtype.

pytest output:

# NVIDIA A100, Python 3.12.3, Torch 2.10.0a0, Triton 3.5.1, NineToothed a63477cd
$ python3 -m pytest -q tests/test_rms_norm.py --tb=short --junitxml=/tmp/ntops-rms-cast-cuda.xml
64 passed in 907.77s

# Additional AOT/reload probe, FP32 and FP16, explicit dtype/block_size=256
rms_norm_aot_reload float32 passed
rms_norm_aot_reload float16 passed
CUDA RMSNorm AOT matrix passed

Ascend validation used 910B4, Python 3.11.13, Torch/torch_npu 2.6.0, triton-ascend 3.2.0, NineToothed PR #240 plus stacked PR ssen0829/ninetoothed#2:

• RMSNorm FP32 and FP16 passed JIT and AOT/reload with block size 256.
• BF16 AOT still fails inside triton-ascend 3.2 triton-adapter-opt with SIGSEGV; this is a compiler-level limitation independent of the epsilon cast.
• Ruff checks the changed file and focused formatting pass; the repository-wide Ruff workflow currently fails on pre-existing formatting and lint findings outside this change.