pytorch / pytorch/pytorch

torch.compile accepts rand_like on an integer tensor that eager rejects, and returns an all-zero tensor

Open
#195,673 0 comments 0 reactions 0 assignees View on GitHub
bot-triaged module: correctness (silent) module: error checking module: inductor module: random 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.rand_like` on an integer tensor is rejected in eager — uniform sampling is not implemented for integral types. Under `torch.compile` the call is accepted and returns a tensor **of all zeros**, so code asking for random values silently receives a constant.

## Reproduction

```python
import torch

def f(x):
return torch.rand_like(x)

x = torch.ones(4, dtype=torch.int64)

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, out.tolist())
```

```
eager: NotImplementedError: "check_uniform_bounds" not implemented for 'Long'
compiled: torch.int64 [0, 0, 0, 0]
```

Same for the other integral dtypes:

| input dtype | eager | compiled |
|---|---|---|
| `int64` | `NotImplementedError: "check_uniform_bounds" not implemented for 'Long'` | `[0, 0, 0, 0]` |
| `int32` | `... not implemented for 'Int'` | `[0, 0, 0, 0]` |
| `uint8` | `... not implemented for 'Byte'` | `[0, 0, 0, 0]` |

## Why the result is worse than the missing check

`rand_like` draws from `[0, 1)`; truncating those samples to an integral dtype gives `0` for every element. So the compiled path does not merely skip eager's check — it returns a constant zero tensor where the caller asked for randomness. Anything downstream that depends on the values being random (a dropout mask, a sampling step, a randomised augmentation) silently degenerates, and there is no warning.

## Versions

Reproduces identically on:

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

CPU, Linux x86_64, Python 3.11.

## Additional context

**#144362** tracks a set of operators whose **dtype** checks are missing under `torch.compile`, where the compiled path implicitly casts and produces a normal result. `rand_like` is not among the operators listed there, and the failure mode here is different: the output is not an implicitly-cast version of the eager answer — eager has no answer, and the compiled one is a degenerate constant.

Found by differential testing over StarCoder-generated programs; 18 independently generated programs in the corpus hit this, all through `rand_like` applied to an integer tensor.

cc @malfet @pbelevich @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 supplied torch.rand_like reproduction and the torch.compile(..., backend="inductor") entry point, testing int64, int32, and uint8 inputs against eager behavior. Trace how compiled rand_like handles integral dtypes and add regression coverage; done means compiled execution no longer silently returns an all-zero tensor where eager rejects the operation.

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
Clearly specified
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.