PyTorch Community Reports Numerical Anomaly in ROCm Compilation; Certain Probability Calculations May Be Distorted

On September 26, the PyTorch community reported that a compiled calculation involving a particular truncated normal distribution on AMD MI355X turns an interval probability that should be zero into one. The case uses PyTorch 2.11.0 and ROCm 7.14.1. As of review, the issue remains open, with no related fix available. [Issue report](https://github.com/pytorch/pytorch/issues/198734)

The calculation uses `log_ndtr`, which computes the logarithm of the standard normal cumulative probability. The example first clamps the interval boundaries to the truncation point, then subtracts two function values that should be identical. The reporter’s analysis suggests that the backend uses different floating-point fusion strategies for the two operations, preventing cancellation; a subsequent exponential operation amplifies the difference. This is the current diagnosis and has yet to be independently confirmed. [Function definition](https://docs.pytorch.org/docs/2.14/special.html#torch.special.log_ndtr), [reproduction and analysis](https://github.com/pytorch/pytorch/issues/198734)

At the execution level, `torch.compile` captures the computation graph and, by default, delegates to TorchInductor to generate accelerator code, with Triton serving as a key component of the GPU path. Validation therefore needs to cover the kernels actually generated and the compilation settings used. A correct source formula and passing tests in eager mode are not enough to establish that the deployment path is correct. This is also why regression tests should record hardware and software versions. [Compiler architecture](https://docs.pytorch.org/docs/stable/torch.compiler.html)

This kind of issue is separate from whether a model can run successfully. The official documentation notes that single precision provides about seven significant decimal digits, and changing the order of additions and multiplications can affect results; mathematically equivalent computations are not guaranteed to produce bitwise-identical results. The engineering question is whether the error meets application requirements, especially when later steps involve subtraction, division, or exponentiation. Comparing only the relative difference between intermediate values is not sufficient. [Numerical accuracy notes](https://docs.pytorch.org/docs/main/notes/numerical_accuracy.html)

The failure pattern in the report changes with the compilation history. After adding `emulate_precision_casts=True`, both rounds passed for all 21 shapes tested. The source code also confirms that the runtime passes the floating-point fusion control option to Triton, but the performance cost of disabling optimizations still needs to be measured. [Test results](https://github.com/pytorch/pytorch/issues/198734), [compiler option forwarding](https://github.com/pytorch/pytorch/blob/v2.11.0/torch/_inductor/runtime/triton_heuristics.py)

For teams maintaining probabilistic models, this article recommends including boundary values, very small variances, and repeated compilation across different shapes in regression tests, and comparing results with eager execution. Teams should also check probability bounds and sums to prevent average error metrics from masking localized failures. Follow-up questions include whether maintainers can reproduce the issue on a newer version, which compiler layer will receive a fix, and whether the workaround affects throughput. This analysis is labeled AI-generated and reviewed by the reporter. CUDA and other AMD architectures were not tested, so the issue cannot yet be generalized as a broad defect. [Report scope and limitations](https://github.com/pytorch/pytorch/issues/198734)