`-fp-mode precise` does not disable FMA contraction on CUDA/NVRTC — PTX is byte-identical to `default`

[jvepsalainen-nv]

Target: Slang, source/compiler-core/slang-nvrtc-compiler.cpp (the empty
case FloatingPointMode::Precise: at ~:1209).

Summary

-fp-mode precise is documented as "Disable optimization that could change the
output of floating-point computations". FMA contraction changes results — it keeps
the intermediate product at higher precision, so a*b+c does not round the same
way as a separate multiply and add. NVRTC contracts by default (--fmad=true),
and Slang's Precise case for NVRTC is empty, so nothing suppresses it.

This is the same defect, on a different target, that #11933 reported and #11935
fixed for SPIR-V by emitting NoContraction.

Reproducer

fma.slang:

RWStructuredBuffer<float> gOut;
[shader("compute")][numthreads(1,1,1)]
void computeMain(uint3 tid : SV_DispatchThreadID)
{
    float a = gOut[0], b = gOut[1], c = gOut[2];
    gOut[3] = a * b + c;
}

slangc fma.slang -target ptx -entry computeMain -stage compute -o default.ptx
slangc fma.slang -target ptx -entry computeMain -stage compute -fp-mode precise -o precise.ptx

Evidence

invocation	emitted PTX for a * b + c
default	fma.rn.f32 %f4, %f1, %f2, %f3;
-fp-mode precise	fma.rn.f32 %f4, %f1, %f2, %f3; — byte-identical to default
-fp-mode precise -Xnvrtc --fmad=false	mul.rn.f32 + add.rn.f32

cmp reports the default and precise PTX files as identical, so precise
currently has no effect whatsoever on this path.

Suggested fix

Pass --fmad=false from the Precise case in slang-nvrtc-compiler.cpp:

case FloatingPointMode::Precise:
    {
        cmdLine.addArg("--fmad=false");
        break;
    }

--fmad=false alone is the complete fix — verified. NVRTC's other
precision-relevant defaults are already at their precise settings
(--prec-div=true, --prec-sqrt=true, --ftz=false), so passing all four
produces byte-identical PTX to passing only --fmad=false (checked on a shader
exercising multiply-add, divide, sqrt and transcendentals). No other flag needs to
be added.

Why this is the right layer

The contraction decision belongs to the downstream compiler, and Slang already owns
the translation from -fp-mode to downstream flags for every other backend
(-Gis for DXC, D3DCOMPILE_IEEE_STRICTNESS for FXC, /fp:precise for MSVC).
The NVRTC case is simply unimplemented rather than deliberately empty; there is no
IR- or emit-level work required, and no Slang-side representation question.

Limits of what was measured

• PTX inspection only. No runtime numerics were compared, so the magnitude of the
  accuracy difference contraction causes on real shaders is not quantified here —
  only that the emitted instruction changes.
• Performance impact of --fmad=false was not measured. Disabling contraction will
  cost some throughput; that is the expected and intended price of precise, but a
  reviewer may want a number before enabling it by default.
• Only the CUDA/NVRTC path was checked. Metal, WGSL and GLSL emit identical source
  under both modes, so whatever their downstream compilers do about contraction is
  likewise uncontrolled by -fp-mode — worth a separate look, not covered here.
• The reproducer is the six-line fma.slang quoted above.

Related

• -fp-mode precise has no effect on SPIR-V output (no NoContraction emitted) #11933 / Emit NoContraction under -fp-mode precise on direct SPIR-V #11935 — the same defect on SPIR-V: -fp-mode precise emitted no
  NoContraction. Fixed by making the SPIR-V emitter honour the mode. This issue is
  that fix's missing CUDA counterpart.
• precise qualifier is ignored on SPIR-V: no NoContraction, and the expression is algebraically reassociated #12198 — precise qualifier ignored on SPIR-V. Adjacent: both are cases where
  a precision request does not reach the code that would have to honour it.
• The "default" option for "-fp-mode" behaves differently depending on the target #6598 — -fp-mode default behaving differently per target. Related in that each
  backend currently implements only one half of the fast/precise switch; on NVRTC
  it is fast that is wired up and precise that is empty.

Found while establishing what -fp-mode actually switches on each target; the
verification that --fmad=false alone suffices was done by comparing PTX with all
four precision flags against PTX with only that one.

[nv-slang-bot]

Triage — confirmed, ready for fix. Thanks for the exceptionally thorough report; the analysis holds up end-to-end.

• Status: Reproduced on top-of-tree (HEAD cc5f4d7f5, slangc 2026.13.1-50-g3649fb982, NVRTC 12.6). default.ptx and precise.ptx are byte-identical (both emit fma.rn.f32, 8392 B); -fp-mode precise -Xnvrtc --fmad=false changes it to mul.rn.f32 + add.rn.f32 — so --fmad=false is confirmed to be the lever, and precise is currently a no-op on this path.
• Root cause: The per-backend switch (options.floatingPointMode) in source/compiler-core/slang-nvrtc-compiler.cpp (~:1205) wires the Fast arm (--use_fast_math) but leaves the Precise arm empty, so NVRTC's default --fmad=true contraction is never suppressed. This is the CUDA/NVRTC counterpart of -fp-mode precise has no effect on SPIR-V output (no NoContraction emitted) #11933 (fixed for direct SPIR-V by Emit NoContraction under -fp-mode precise on direct SPIR-V #11935 via NoContraction).
• Verdict: Valid bug, classified bug / medium / target-emit (CUDA-NVRTC). Your suggested layer is right — the contraction decision belongs to the downstream-flag translation Slang already owns per backend (DXC -Gis, FXC D3DCOMPILE_IEEE_STRICTNESS, MSVC /fp:precise); no IR/emit change is warranted for the global -fp-mode. Not a duplicate.
• Next action: Handed to an implementation coworker with the recommended one-line fix (cmdLine.addArg("--fmad=false"); in the Precise arm) plus a CI-runnable PTX FileCheck regression test (PTX generation is NVRTC compile-only, so it needs no GPU). Marked Type=Bug and applied reproduced.
• Blocker: None for this fix. Your flagged open items are noted as out of scope here: (1) no runtime accuracy-magnitude / (2) --fmad=false perf cost measured — the reviewer may want a number, though it is the intended cost of precise; (3) Metal/WGSL/GLSL contraction being likewise uncontrolled by -fp-mode is a separate issue worth filing on its own.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[nv-slang-bot]

A draft fix is up: #12801 (branch fix/issue-12799).

• Status: fix implemented, verified locally; held as draft pending peer review + CI.
• Approach: fills the empty FloatingPointMode::Precise arm of the NVRTC downstream-flag switch with --fmad=false (symmetric with the existing Fast → --use_fast_math) — the CUDA/NVRTC counterpart of the SPIR-V fix in Emit NoContraction under -fp-mode precise on direct SPIR-V #11935. --fmad=false alone suffices since NVRTC's other precision defaults (--prec-div, --prec-sqrt, --ftz) are already precise.
• Test: new CI-runnable PTX regression tests/cuda/fp-mode-precise-fmad.slang — precise emits no fma.rn (separate mul.rn/add.rn), default still contracts. Confirmed it fails without the fix and passes with it (local L40S + NVRTC 12.6).
• Out of scope (per the report): Metal/WGSL/GLSL contraction under -fp-mode, and the per-declaration precise qualifier (precise qualifier is ignored on SPIR-V: no NoContraction, and the expression is algebraically reassociated #12198) — separate issues.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}