pytorch / pytorch/pytorch

torch.clamp with a bound unrepresentable in the tensor dtype: eager raises, torch.compile ignores the bound

Open
#195,675 4 comments 0 reactions 0 assignees View on GitHub
bot-triaged module: correctness (silent) module: decompositions module: inductor oncall: pt2 release triage topic: fuzzer triaged
Dominant language
Python
Stars
103k
Forks
29.5k
PR merge metrics
PR metrics pending

Description

## 🐛 Describe the bug

`torch.clamp` with a bound that cannot be represented in the tensor's dtype is rejected in eager, but accepted under `torch.compile`, which silently treats the unrepresentable bound as no bound at all.

## Reproduction

```python
import torch

def f(x):
return torch.clamp(x, min=-3.4e39, max=3.4e39) # beyond float32 range

x = torch.randn(4)

with torch.no_grad():
try:
f(x)
except Exception as e:
print("eager:", type(e).__name__ + ":", str(e).splitlines()[0])
out = torch.compile(f, backend="inductor")(x)
print("compiled:", out.dtype, "max|out| =", out.abs().max().item())
```

```
eager: RuntimeError: value cannot be converted to type float without overflow
compiled: torch.float32 max|out| = 0.8913
```

`torch.clamp_min(x, -3.4e39)` behaves the same way.

## Versions

Reproduces identically on:

- PyTorch `2.11.0`
- PyTorch `2.14.0+cpu`

CPU, Linux x86_64, Python 3.11.

## Additional context

The compiled answer here is arguably the reasonable one — a bound outside the dtype's range clamps nothing — so this may well be a case where eager is the side worth changing. Either way the two paths disagree on the same program: one refuses to run it, the other returns a result.

Related but not the same: **#144362** collects operators missing a **dtype** check under `torch.compile`; this is a value-representability check on a scalar argument rather than a dtype check on a tensor, and `clamp` is not in that issue's list.

Found by differential testing over StarCoder-generated programs; 7 independently generated programs in the corpus hit this through `clamp` / `clamp_min` / `clamp_max` with an out-of-range bound.

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @kadeng @muchulee8 @amjames @aakhundov @coconutruben @jataylo

Contributor guide

Open the contributing guide

Research direction

Start with the provided Python reproduction using torch.clamp and torch.compile(..., backend="inductor"), then compare eager and compiled handling of out-of-range scalar bounds, including torch.clamp_min. Done means the intended behavior is aligned between both paths and regression coverage demonstrates it for clamp and clamp_min.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.