gopikrsmscs/torch-issues huggingface dataset:
M1 mps issue
Labels: triaged, module: mps

### 🐛 Describe the bug

I've been tracing an issue that arose while using yolov5 object detector/classifier on the recently supported 'mps' device. The issue first manifested itself as objects being detected in the wrong locations (sometimes). Some of the time it performs the detection correctly, which leads me to believe this isn't a major issue.

Tracing the issue: https://github.com/ultralytics/yolov5/issues/10178

It looks like this is a torch issue and not a yolo issue. 

I would really appreciate some help tracing the root of the problem further, or even some hints on where to look next.



### Versions

```
PyTorch version: 1.14.0.dev20221116
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.3 (arm64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.5)
CMake version: Could not collect
Libc version: N/A

Python version: 3.10.6 | packaged by conda-forge | (main, Aug 22 2022, 20:38:29) [Clang 13.0.1 ] (64-bit runtime)
Python platform: macOS-12.3-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.4
[pip3] torch==1.14.0.dev20221116
[pip3] torchaudio==0.14.0.dev20221116
[pip3] torchvision==0.15.0.dev20221116
[conda] numpy                     1.23.4                   pypi_0    pypi
[conda] torch                     1.14.0.dev20221116          pypi_0    pypi
[conda] torchaudio                0.14.0.dev20221116          pypi_0    pypi
[conda] torchvision               0.15.0.dev20221116          pypi_0    pypi
```

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
amd windows
Labels: module: windows, module: rocm, triaged

### 🚀 The feature, motivation and pitch

add it for amd windows too

### Alternatives

_No response_

### Additional context

_No response_

cc @peterjc123 @mszhanyi @skyline75489 @nbcsm @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport
TensorWithTFOverrideVariable don't store fake tensor (they store real tensor)
Labels: triaged, oncall: pt2, module: dynamo

### 🐛 Describe the bug

The proximal cause for the problem is this line in utils.py:

```
    def wrap_to_fake_tensor(e, fake_mode):
        if type(e) in (torch.Tensor, torch.nn.Parameter):
            return wrap_fake_exception(
                lambda: make_fake_tensor(
                    e, fake_mode, static_shapes=config.dynamic_shapes is False
                )
            )
        else:
            return e
```

When we attempt to wrap the tensor to become fake, we bypass this process if it's not exactly a Tensor or Parameter. This means the real tensor gets stored on `example_value`.

This causes problems for dynamic shape guards as failing to fakeify the tensor here means subsequent call to `super().__torch_function__` looks at the returned tensor and says "well golly I've never seen this tensor before, I guess it must be an input" and generates guards that are impossible to actually fulfill.

cc @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @vkuzo 

### Error logs

_No response_

### Minified repro

_No response_
Enable NCCL for PyTorch on Windows
Labels: oncall: distributed, module: windows, triaged

PyTorch has several backends for [distributed computing](https://pytorch.org/docs/stable/distributed.html). One of them is NVidia NCCL where main benefit is distributed computing for most Devices on GPU.

Unfortunately NVidia NCCL is not supported on Windows, but it is supported for other platforms. 

Goal of this ticket is map importance of this feature, find out blockers and if needed start up work stream on this feature.

**Open questions**
- Investigate impact of missing NCCL support (Who needs it? Is it important for Windows to support it?)
- If NCCL support is important for Windows, are there any blockers? What needs to be done to support it?

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @peterjc123 @mszhanyi @skyline75489 @nbcsm
Dynamo is over-guarding on Tensor locals
Labels: triaged, bug

### 🐛 Describe the bug

two for one example:

```
import torch
import torch._dynamo

def g(x, y, z):
    return x * 2 + 1

@torch._dynamo.optimize("eager")
def f(x, y, z):
    print("woof")
    z = x * 2
    z = x + 1
    print("warf")
    return g(z, y, z)

f(torch.randn(2), torch.randn(3), 4)
```

The graph between woof and warf generates a TENSOR_MATCH guard on y. The function call to g generates a TENSOR_MATCH guard on y. In both cases, this guard is completely unnecessary.

The extra guards here are especially pernicious because if you have a long function body with some graph breaks, the intermediate fragments will guard on ALL of the inputs, even if the broken up subgraphs only deal with a subset of variables.

### Error logs

_No response_

### Minified repro

_No response_
PTX codegen race?
Labels: triaged, bug, oncall: pt2

### 🐛 Describe the bug

See CI log at https://github.com/pytorch/pytorch/actions/runs/3545111323/jobs/5953152353

### Error logs

_No response_

### Minified repro

_No response_

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh
`positive_semidefinite` constraint fails on CUDA 11.7
Labels: module: distributions, triaged, module: linear algebra

### 🐛 Describe the bug

Using PyTorch 1.12.1 with CUDA 11.7 I'm seeing a test failure in `test_constraints`.

The issue can be reproduced by: 

```
$ python -c 'import torch; print(torch.distributions.constraints.positive_semidefinite.check(torch.cuda.DoubleTensor([[1., 2], [2., 4]])))'
tensor(False, device='cuda:0')
```

The CPU version works:
```
$ python -c 'import torch; print(torch.distributions.constraints.positive_semidefinite.check(torch.DoubleTensor([[1., 2], [2., 4]])))'
tensor(True)
```

I further traced this down to the use of CUSolver for `syevd`:
```
$ python -c 'import torch; print(torch.linalg.eigvalsh(torch.cuda.DoubleTensor([[1., 2], [2., 4]])))'
tensor([-4.1211e-34,  5.0000e+00], device='cuda:0', dtype=torch.float64)
```

The correct result (on CPU and WolframAlpha) is `tensor([0., 5.], dtype=torch.float64)`

In a[ related issue](https://github.com/pytorch/pytorch/issues/41688#issuecomment-661633369) @vishwakftw wrote 

> I believe this is not an actual issue.

but as for such checks this seems to be an example where it is an issue, so I'd request to review this.

### Versions

PyTorch 1.12.1
CUDA 11.7

cc @fritzo @neerajprad @alicanb @nikitaved @jianyuh @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
MPS device ComplexFloat
Labels: triaged, module: fft, module: mps

### 🐛 Describe the bug

Hello, I am using torch 1.13 on my mac with M1 chip and I want to calculate the fft2 on a image. My target is to use it in the Focal Frequency Loss described [here](https://arxiv.org/pdf/2012.12821.pdf).

I simply do
   
    import torch

    img = img.unsqueeze(0).to("mps:0") # img has now shape (1, 3, 480, 640) preprocessed before using monai transforms
    freq = torch.fft.fft2(img, norm="ortho")

and I get this message error:

    Output exceeds the [size limit](command:workbench.action.openSettings?[). Open the full output data [in a text editor](command:workbench.action.openLargeOutput?78c97743-d5c9-4858-99cb-94815ed4009d)
    ---------------------------------------------------------------------------
    TypeError                                 Traceback (most recent call last)
    Cell In [9], line 2
          1 img = img.unsqueeze(0).to("mps:0")
    ----> 2 freq = torch.fft.fft2(img, norm="ortho")

    File  ~/miniforge3/envs/torch13/lib/python3.10/site-packages/monai/data/meta_tensor.py:249, in 
    MetaTensor.__torch_function__(cls, func, types, args, kwargs)
        247 if kwargs is None:
        248     kwargs = {}
    --> 249 ret = super().__torch_function__(func, types, args, kwargs)
        250 # if `out` has been used as argument, metadata is not copied, nothing to do.
        251 # if "out" in kwargs:
        252 #     return ret
        253 # we might have 1 or multiple outputs. Might be MetaTensor, might be something
        254 # else (e.g., `__repr__` returns a string).
        255 # Convert to list (if necessary), process, and at end remove list if one was added.
        256 if (
        257     hasattr(torch, "return_types")
        258     and hasattr(func, "__name__")
       (...)
        262 ):
        263     # for torch.max(torch.tensor(1.0), dim=0), the return type is named-tuple like

    File ~/miniforge3/envs/torch13/lib/python3.10/site-packages/torch/_tensor.py:1278, in Tensor.__torch_function__(cls, func,types, args, kwargs)
       1275     return NotImplemented
    ...
    -> 1278     ret = func(*args, **kwargs)
       1279     if func in get_default_nowrap_functions():
       1280         return ret

    TypeError: Trying to convert ComplexFloat to the MPS backend but it does not have support for that dtype.

It works when the image is not sent to MPS:

    img = img.unsqueeze(0)
    freq = torch.fft.fft2(img, norm="ortho")
    mag = torch.sqrt(freq.real.pow(2) + freq.imag.pow(2))
    mag.shape

and I get:

    (1, 3, 480, 640)

thanks in advance for the help.

### Versions

my installed packages are:

- python 3.10.6
- torch 1.13
- monai 1.0.1

cc @mruberry @peterbell10 @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
torchinductor tests attempt to access internet
Labels: triaged, bug

### 🐛 Describe the bug

Run the tests somewhere without an outbound internet connection, e.g.,

```
$ python test/inductor/test_torchinductor.py -k test_cudnn_rnn  
```


```
CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://conda.anaconda.org/conda-forge/linux-64/curre
nt_repodata.json>                                                                                        
Elapsed: -                                                                                               
                                                                                                         An HTTP error occurred when trying to retrieve this URL.                                                 
HTTP errors are often intermittent, and a simple retry will get you on your way.                         
'https://conda.anaconda.org/conda-forge/linux-64'                                                        
                                                                                                         
                                               
```

### Error logs

_No response_

### Minified repro

_No response_
[dynamo] RuntimeError: Failed running call_function aten.nll_loss_backward(*(FakeTensor(FakeTensor(...
Labels: triaged, module: dynamo

### 🐛 Describe the bug

I'm seeing the following error when running with dynamo

```
RuntimeError: Failed running call_function aten.nll_loss_backward(*(FakeTensor(FakeTensor(..., device='meta', size=(1,)), cpu), FakeTensor(FakeTensor(..., device='meta', size=(3,)), cpu)), **{'target': FakeTensor(FakeTensor(..., device='meta', size=(3,), dtype=torch.int64), cpu), 'weight': None, 'reduction': 0, 'ignore_index': 10, 'total_weight': FakeTensor(FakeTensor(..., device='meta', size=()), cpu)}):
Index tensor must have the same number of dimensions as self tensor
```

repro:

```python
import torch
import torch._dynamo as dynamo


@dynamo.optimize("eager")
def forward(grad_output, input, target, total_weight):
    return torch.ops.aten.nll_loss_backward(grad_output,
                                            input,
                                            target=target,
                                            weight=None,
                                            reduction=0,
                                            ignore_index=10,
                                            total_weight=total_weight)


forward(torch.randn(1), torch.randn(3), torch.tensor([2, 3, 0]),
        torch.tensor(3.))
```

Full error log: https://gist.github.com/silvasean/5dd4b1667c9e451d12dac84e8a473173

### Versions

Collecting environment information...
PyTorch version: 1.14.0.dev20221114+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux rodete (x86_64)
GCC version: (Debian 12.2.0-3) 12.2.0
Clang version: 14.0.6-2
CMake version: version 3.25.0
Libc version: glibc-2.35

Python version: 3.10.8 (main, Nov 3 2022, 15:17:13) [GCC 12.2.0] (64-bit runtime)
Python platform: Linux-5.18.16-1rodete4-amd64-x86_64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.4
[pip3] torch==1.14.0.dev20221114+cpu
[pip3] torchvision==0.15.0.dev20221114+cpu
[conda] Could not collect

cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire
[dynamo] RuntimeError: Failed running call_function aten.convolution_backward(*(FakeTensor(FakeTensor(..
Labels: triaged, module: dynamo

### 🐛 Describe the bug


```
TypeError: new_empty(): argument 'size' (position 1) must be tuple of ints, but found element of type NoneType at pos 0
...
RuntimeError: Failed running call_function aten.convolution_backward(*(FakeTensor(FakeTensor(..., device='meta', size=(2, 2, 8, 8)), cpu), FakeTensor(FakeTensor(..., device='meta', size=(2, 2, 6, 6)), cpu), FakeTensor(FakeTensor(..., device='meta', size=(2, 2, 3, 3)), cpu)), **{'bias_sizes': None, 'stride': [1, 1], 'padding': [2, 2], 'dilation': [1, 1], 'transposed': False, 'output_padding': [0], 'groups': 1, 'output_mask': [True, True, True]}):
new_empty(): argument 'size' (position 1) must be tuple of ints, but found element of type NoneType at pos 0
(scroll up for backtrace)
```


```python
import torch
import torch._dynamo as dynamo

@dynamo.optimize("eager")
def forward(grad_out, input_vec, weight):
    return torch.ops.aten.convolution_backward(
        grad_out,
        input_vec,
        weight,
        bias_sizes=None,
        stride=[1, 1],
        padding=[2, 2],
        dilation=[1, 1],
        transposed=False,
        output_padding=[0],
        groups=1,
        output_mask=[True, True, True])


forward(torch.randn(2, 2, 8, 8), torch.randn(2, 2, 6, 6),
        torch.randn(2, 2, 3, 3))
```

Full error log: https://gist.github.com/silvasean/068ec6759d9f29f0b9255e5fc1c62e0a

### Versions

Collecting environment information...
PyTorch version: 1.14.0.dev20221114+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux rodete (x86_64)
GCC version: (Debian 12.2.0-3) 12.2.0
Clang version: 14.0.6-2
CMake version: version 3.25.0
Libc version: glibc-2.35

Python version: 3.10.8 (main, Nov 3 2022, 15:17:13) [GCC 12.2.0] (64-bit runtime)
Python platform: Linux-5.18.16-1rodete4-amd64-x86_64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.4
[pip3] torch==1.14.0.dev20221114+cpu
[pip3] torchvision==0.15.0.dev20221114+cpu
[conda] Could not collect

cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire
[dynamo] RuntimeError: Failed running call_function aten.lift_fresh_copy(*(FakeTensor(FakeTensor(...
Labels: triaged, module: dynamo

### 🐛 Describe the bug

I'm observing this error from the following minimal repro.

```
RuntimeError: Failed running call_function aten.lift_fresh_copy(*(FakeTensor(FakeTensor(..., device='meta', size=(2, 3)), cpu),), **{}):
maximum recursion depth exceeded while calling a Python object
```


```
import torch
import torch._dynamo as dynamo

@dynamo.optimize("eager")
def forward(x):
    return torch.ops.aten.lift_fresh_copy(x)

forward(torch.randn(2, 3))
```


Full error log: https://gist.github.com/silvasean/3ff689aea2a9da64d20899ff159ab52e

### Versions

Collecting environment information...
PyTorch version: 1.14.0.dev20221114+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux rodete (x86_64)
GCC version: (Debian 12.2.0-3) 12.2.0
Clang version: 14.0.6-2
CMake version: version 3.25.0
Libc version: glibc-2.35

Python version: 3.10.8 (main, Nov  3 2022, 15:17:13) [GCC 12.2.0] (64-bit runtime)
Python platform: Linux-5.18.16-1rodete4-amd64-x86_64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.4
[pip3] torch==1.14.0.dev20221114+cpu
[pip3] torchvision==0.15.0.dev20221114+cpu
[conda] Could not collect

cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire
Can not access to "sbgemm" routine with user-defined OpenBLAS
Labels: module: build, triaged, module: bfloat16, module: openblas

### 🐛 Describe the bug

I want to build a pytorch with OpenBLAS and use sbgemm.

If OpenBLAS is installed in the default path and BLAS is not specified when pytorch build, it will go to FindBLAS.cmake and set BLAS_HAS_SBGEMM.

However, if I specify the OpenBLAS path in the following way, and specify BLAS as OpenBLAS:
```bash
 OpenBLAS_HOME=<My OpenBLAS Path> BLAS=OpenBLAS MAX_JOBS=16 python setup.py develop
```
It will go to FindOpenBLAS.cmake but not FindBLAS.cmake, and not set BLAS_HAS_SBGEMM. Finally, the built PyTorch cannot use the GEMM support for BFloat16.

### Versions

Collecting environment information...
PyTorch version: 1.14.0a0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Ubuntu Jammy Jellyfish (development branch) (aarch64)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.35

Python version: 3.10.6 (main, Nov  2 2022, 18:53:38) [GCC 11.3.0] (64-bit runtime)
Python platform: Linux-5.10.134-12.2.al8.aarch64-aarch64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.4
[pip3] torch==1.14.0a0+gitunknown
[pip3] torchvision==0.14.0a0
[conda] Could not collect

cc @malfet @seemethere
NVFuser failing masked.{amax|amin|sum} extremal and correctness tests
Labels: triaged, module: nvfuser

### 🐛 Describe the bug

See https://github.com/pytorch/pytorch/actions/runs/3535610687/jobs/5934088992

### Versions

https://github.com/pytorch/pytorch/pull/87880

cc @kevinstephano @jjsjann123
Caching a model's weights and state_dict to disk to save RAM
Labels: module: nn, triaged

### 🚀 The feature, motivation and pitch

Hello, is there a way that I could cache a model's weights to the disk to save RAM? Similar to how the `.cpu` could be invoked to move the model's weights from the GPU to the CPU to save VRAM. There was an [issue](https://github.com/pytorch/pytorch/issues/24119) on this from a few years ago on MMAPed tensors from disk but I haven't been able to find anything on achieving something similar with model weights and state dicts.  I'm not sure if this is possible in the current PyTorch implementation but any help would be much appreciated.

### Alternatives

`torch.load` but that incurs basically the same time penalty as just loading a model directly from the disk. 

### Additional context

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
[Inductor] [CPU] LSTM is not using oneDNN in tts_angular
Labels: triaged

### Description

Comparing the performance of `tts_angular` between inductor and IPEX backend, inductor is worse than IPEX due to LSTM OP.
In IPEX, LSTM is using oneDNN lstm primitive while in inductor, LSTM falls back to PyTorch (not using oneDNN).


### Profiling
<html>
<body>
<!--StartFragment-->

tts_angular | IPEX (LSTM uses oneDNN) | inductor (LSTM uses stock PyTorch)
-- | -- | --
occurrences | 3 | 3
LSTM time | 52.031ms | 104.763ms
Total time | 59.767ms | 109.785ms
LSTM time / Total time | 87.06% | 95.43%

<!--EndFragment-->
</body>
</html>
[accuracy] [aot_eager] mobilenet_v2_quantized_qat fails accuracy 
Labels: triaged, bug, oncall: pt2, module: dynamic shapes, module: aotdispatch

### 🐛 Describe the bug

I am expecting `aot_eager` to be really close to pytorch native for any model. But, `mobilenet_v2_quantized_qat` fails accuracy. Minifier is not helping here (I am going to dive deeper into this). So, a couple of questions

1) Is something special about this model that can affect the accuracy?
2) Long time ago - I relaxed the accuracy check for another similar model `resnet50_quantized_qat`, and used cosine similarity. But, I think its too relaxed. If I tighten the check back, this model fails accuracy as well.

`python benchmarks/dynamo/torchbench.py --training --accuracy --device cuda --backend=aot_eager --float32 --only=mobilenet_v2_quantized_qat`

### Error logs

_No response_

### Minified repro

_No response_

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
Partitioner generates useless constant SymInt edges between forward-backwards
Labels: triaged, bug, oncall: pt2

### 🐛 Describe the bug

Suppose you have a size saved for backwards; at time of tracing that node, it was symbolic. However, later, we discovered it was in fact constant (because, e.g., we added it to a parameter). The FX graph still passes the symbolic shape around, but we happen to know it's constant. Fine. Then, we run the partitioner. The partitioner can't tell that a SymInt is constant, and will generate an edge from forwards to backwards to transfer the constant int, which is totally unnecessary.

Symbolic shapes branch is currently hacking around this with https://github.com/pytorch/pytorch/pull/84246/commits/1a5ff545370639f17d40f5f6157eefd9fc74d93b which forces constant nodes to get const propagated before we partition.

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh

### Error logs

_No response_

### Minified repro

_No response_
AOTAutograd generates useless tangent inputs for SymInt outputs
Labels: triaged, bug, oncall: pt2

### 🐛 Describe the bug

If you AOTAutograd a graph that returns an int, the joint forward-backward will take an int tangent for this argument. This is useless. It is also wrong: the int tangent will be specified to be a specific symbolic int, but in fact you will always get None instead from the autograd engine. 

This is annoying to fix because we must determine what the tangents to pass in are outside of the joint forwards backwards, but the calculation what actually needs tangents is inside joint forward backwards. Need to hoist it out.

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh @bhdirsh

### Error logs

_No response_

### Minified repro

_No response_
Feature Request: deterministic CUDA cumsum
Labels: feature, module: cuda, triaged, module: determinism

### 🚀 The feature, motivation and pitch

There is no deterministic implementation for `cumsum_cuda_kernel`. It would be nice to have this!

### Alternatives

_No response_

### Additional context

This can currently still be used by setting the `warn_only` flag to `True`.
Warning:
`cumsum_cuda_kernel does not have a deterministic implementation, but you set 'torch.use_deterministic_algorithms(True, warn_only=True)'. You can file an issue at https://github.com/pytorch/pytorch/issues to help us prioritize adding deterministic support for this operation. (Triggered internally at ../aten/src/ATen/Context.cpp:82.)`

cc @ngimel @mruberry @kurtamohler
build: cmake: functorch.so not installed at expected location
Labels: module: build, triaged

### 🐛 Describe the bug

When building with cmake, the functorch library gets installed to `${DESTDIR}/${PROJECT_SOURCE_DIR}/functorch/`, which is unexpected:

```sh
$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr ...
...
$ make install DESTDIR=$PWD/install
...
$ ls install
home  usr
$ find install/home
install/home/$USER/path/to/pytorch.git/functorch/functorch.so
```

The functorch library is moved by setup.py later, but nevertheless I'd expect that unless the quirk is documented, the cmake stage installed files in standard locations.

### Versions

pytorch cf9476554fce9a9c909eebd7439f4b3f4d208f6c

cc @malfet @seemethere
build: cmake: ability to disable -Werror* (-Werror considered harmful)
Labels: module: build, triaged

### 🐛 Describe the bug

Tried to compile pytorch with gcc 12 and it failed instead of warning due to `-Werror`.

Now while I'm convinced that leaving `-Werror` in the build files elsewhere than in the developer / CI environment is insanity, and I'm not alone (https://flameeyes.blog/2009/02/25/future-proof-your-code-dont-use-werror/ ; https://embeddedartistry.com/blog/2017/05/22/werror-is-not-your-friend/ ; https://news.ycombinator.com/item?id=28745949 ...), I'm simply requesting the ability of controlling it (eg. https://github.com/dotnet/runtime/issues/7122 ; https://github.com/RobotLocomotion/drake/issues/2428 ...) so source distribution is future-proof.

### Versions

PyTorch version: 1.13.0+cu117

cc @malfet @seemethere
build: cmake: need to uniformize installation of libraries in CMAKE_INSTALL_LIBDIR (not lib)
Labels: module: build, module: cpp, triaged, needs research

### 🐛 Describe the bug

Installed pytorch from source, with cmake.

In particular I noticed that some libraries are installed in a hard-coded `$DESTDIR/$CMAKE_INSTALL_PREFIX/lib`, which is not expected on x86_64 (should be `.../lib64` from `CMAKE_INSTALL_LIBDIR`).

Looking at the cmake files:
```sh
git grep CMAKE_INSTALL_LIBDIR
git grep "DESTINATION lib"
```
and found issues.

So I propose to do this:
```sh
git grep " lib)" | perl -pe 's/(.*):(.*)$\s*/\1/g' | grep CMakeLists.txt | uniq | while read file; do sed -i -e 's@ lib)@ ${CMAKE_INSTALL_LIBDIR})@' "$file"; done
```
then reviewing with `git gui` or something else, to get rid of false positives (eg. test executables shouldn't go there, and it's OK for the deployed platform-agnostic `.py` files to be in `.../lib`).


### Versions

PyTorch version: 1.13.0+cu117

cc @malfet @seemethere @jbschlosser
Unexpected behavior from torchscript (mixing trace with script)
Labels: oncall: jit

### 🐛 Describe the bug

Hi,

I have encountered some unexpected behavior with mixing torch.jit.script and torch.jit.trace. Here’s a example to reproduce.

```python
import torch
import numpy as np

@torch.jit.script
def select_rows(
    nums: int,
    data: torch.Tensor,
    size: int
):
    valid_choice = torch.multinomial(torch.ones(nums).float(), size)
    return data[valid_choice]

def do_selection(x):
    return select_rows(x.shape[0], x, x.shape[0])

t_4 = torch.tensor(np.array([1, 2, 3, 4]))
t_7 = torch.tensor(np.array([1, 2, 3, 4, 5, 6, 7]))

traced_selection = torch.jit.trace(do_selection, t_4)

print(traced_selection(t_4))
>>> tensor([3, 1, 2, 4])  # A random arrangement of the input data.

print(traced_selection(t_7))
>>> tensor([1, 3, 2, 4])  
# Another random arrangement, but of the TRACED EXAMPLE!
# Expected a random arrangement of the current input of size 7!
```

In my actual example, def do_selection() is extremely complicated, and cannot be scripted using torch.jit.script . What are my options here? Is this the expected behavior?

Thanks.

### Versions

PyTorch version: 1.10.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.4 (x86_64)
GCC version: Could not collect
Clang version: 13.0.0 (clang-1300.0.27.3)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.13 (main, Aug 25 2022, 18:29:29)  [Clang 12.0.0 ] (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.19.5
[pip3] pytorch-lightning==1.1.4
[pip3] torch==1.10.0
[pip3] torchaudio==0.10.0
[pip3] torchmetrics==0.10.0rc0
[pip3] torchvision==0.11.0
[conda] numpy                     1.19.5                   pypi_0    pypi
[conda] pytorch-lightning         1.1.4                    pypi_0    pypi
[conda] torch                     1.10.0                   pypi_0    pypi
[conda] torchaudio                0.10.0                   pypi_0    pypi
[conda] torchmetrics              0.10.0rc0                pypi_0    pypi
[conda] torchvision               0.11.0                   pypi_0    pypi


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
torch.split: argument 'split_sizes' (position 1) must be tuple of ints, not list
Labels: triaged, module: sorting and selection

### 🐛 Describe the bug

torch.split(tensor, split_sizes, dim=0)   :  split_sizes data type is int or list(int)

    import torch
    tensor = torch.rand([5, 5], dtype=torch.float64)
    split_sizes = [True, 3, False, True]
    out = torch.split(tensor, split_sizes)
    print(out)

result : TypeError: split_with_sizes(): argument 'split_sizes' (position 1) must be tuple of ints, not list

The value of input split_sizes is [True, 3, False, True], which is a list type. Although the value in the list is not necessarily legal, the exception thrown by the following code does not meet the actual requirements. The exception information says split_sizes must be tuple of ints, not list, does not match the official document description.

### Versions

pytorch: 1.12.1
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows
Higher order derivatives of sinc explode
Labels: triaged, module: derivatives, actionable

### 🐛 Describe the bug

First order derivatives of `torch.sinc(x)` are fine at `x=0`: they were previously reported as exploding in https://github.com/pytorch/pytorch/issues/56760 and https://github.com/pytorch/pytorch/issues/53989 and were fixed in https://github.com/pytorch/pytorch/pull/56763.

However, higher order derivatives or `torch.sinc(x)` at `x=0` still explode:

```python
zero = torch.zeros(1, requires_grad = True)
dx = torch.autograd.grad(torch.sinc(zero), zero, create_graph=True)[0]
torch.autograd.grad(dx, zero)[0]
tensor([nan])
```

By reading off the Taylor series of `sinc(x) = sin(x)/x = 1- x^2/3! + x^4/5! ...`, we get that the second derivative should have of limit of `-1/3`.

### Versions

PyTorch version: 1.12.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.5.1 (x86_64)
GCC version: Could not collect
Clang version: 12.0.5 (clang-1205.0.22.11)
CMake version: version 3.22.1
Libc version: N/A

Python version: 3.10.4 (main, Mar 31 2022, 03:38:35) [Clang 12.0.0 ] (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.1
[pip3] torch==1.12.1
[conda] Could not collect


cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Partitioner that doesn't require functionalized graph
Labels: triaged, bug, oncall: pt2

### 🐛 Describe the bug

We should have a partitioner that doesn't require functionalized graph; this would allow us to easily ablate functionalization when debugging issues caused by functionalization.

### Error logs

_No response_

### Minified repro

_No response_

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh
Accuracy minifier can find spurious accuracy failures involving uninitialized memory
Labels: triaged, bug, oncall: pt2

### 🐛 Describe the bug

Suppose you have a graph like

```
y = x.new_empty(10)
y.fill_(0)
```

Suppose you are accuracy minifying. Removing the fill_ will cause an accuracy failure, because the uninitialized memory will trigger a difference. Oops.

Here is a quick and dirty way to remove non-determinism from uninitialized CUDA memory

```
diff --git a/c10/cuda/CUDACachingAllocator.cpp b/c10/cuda/CUDACachingAllocator.cpp
index 9876259522..f54e66138b 100644
--- a/c10/cuda/CUDACachingAllocator.cpp
+++ b/c10/cuda/CUDACachingAllocator.cpp
@@ -2140,6 +2140,7 @@ class NativeCachingAllocator : public CUDAAllocator {
       if (C10_UNLIKELY(interp)) {
         (*interp)->trace_gpu_memory_allocation(reinterpret_cast<uintptr_t>(r));
       }
+      cudaMemset(r, 0, size);
       return {r, r, &uncached_delete, Device(DeviceType::CUDA, device)};
     }
     if (size != 0) {
@@ -2147,6 +2148,7 @@ class NativeCachingAllocator : public CUDAAllocator {
       const_cast<NativeCachingAllocator*>(this)->malloc(
           &r, device, size, cuda::getCurrentCUDAStream(device));
     }
+    cudaMemset(r, 0, size);
     return {r, r, &local_raw_delete, Device(DeviceType::CUDA, device)};
   }
   DeleterFnPtr raw_deleter() const override {
```

Need some sort of proper fix.

### Error logs

_No response_

### Minified repro

_No response_

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh
Accuracy minifier should also work even if an exception is raised
Labels: triaged, bug, oncall: pt2

### 🐛 Describe the bug

If you use accuracy minifier on a model that errors when optimized, the accuracy minifier does nothing. But accuracy minification should be a superset of both testing for accuracy failures AND raised exceptions.

### Error logs

_No response_

### Minified repro

_No response_

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh
Allow `low` and `high` to be tensors in `torch.randint`
Labels: feature, triaged, module: random

### 🚀 The feature, motivation and pitch

In `torch.randint`, allow `low` and `high` to be tensors (currently, only int are allowed), like in `numpy.random.randint`. 

```python
from torch import randint, tensor
randint(3)  # ERROR
randint(3, 7)  # ERROR
randint(3, 7, (3,))  # OK
randint(tensor([0, 1]), tensor([5, 4]))  # ERROR
```

```python
from numpy.random import randint
from numpy import array
randint(3)  # OK
randint(3, 7)  # OK
randint(3, 7, (3,))  # OK
randint(array([0, 1]), array([5, 4]))  # OK
```


### Alternatives

Keep using the following syntax

```python
from torch import concatenate, tensor, randint

lows, highs = tensor([0, 1]), tensor([5, 4])
concatenate([randint(low, high, (1,)) for low, high in zip(lows, highs)])
```

### Additional context

It would require to make the parameter `size` optional.

cc @pbelevich
The problem caused by the parameter dim of torch.norm
Labels: module: error checking, triaged, module: edge cases

### 🐛 Describe the bug

pytorch1.12.1

    code 1 : The test code dim=False, but the thrown exception describes dim as a list.
    
        import torch
        input = torch.rand([5, 5, 5], dtype=torch.float64)
        out = torch.norm(input, p='fro', dim=False, keepdim=False, out=None, dtype=None)
        print(out)
    
    result:    TypeError: frobenius_norm(): argument 'dim' (position 2) must be tuple of ints, not list


    code 2 : The test code dim=False, the exception thrown is correct.
    
        import torch
        input = torch.rand([5, 5, 5], dtype=torch.float64)
        out = torch.norm(input, p='fro', dim="False", keepdim=False, out=None, dtype=None)
        print(out)
    
    result: TypeError: frobenius_norm(): argument 'dim' (position 2) must be tuple of ints, not str


pytorch1.8.0

    code 1 : In the pytorch1.8 version, dim is still set to False, and the program can run successfully, because the program automatically treats False as a value of 0..
    
          import torch
          input = torch.rand([5, 5, 5], dtype=torch.float64)
          out = torch.norm(input, p='fro', dim=False, keepdim=False, out=None, dtype=None)
          print(out)
    
    result:    tensor([[1.3522, 1.1940, 0.7555, 1.3410, 1.3593],
                  [1.0926, 1.0986, 1.3429, 1.0170, 1.1915],
                  [1.1807, 1.4252, 1.5389, 1.2257, 1.5626],
                  [1.5249, 0.9933, 1.2927, 1.7106, 1.6482],
                  [1.1870, 1.0370, 1.6912, 1.0616, 1.0801]], dtype=torch.float64)


Question 1: Why is False treated as a list in the first test code?
Question 2: Why can’t False be treated as a value of 0 on a higher version, because when compiled according to the bottom layer of python, False will be set to 0, so why does the program fail?

### Versions

pytorch: 1.12.1
pytorch: 1.8.0
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows
fx.wrap is ignored with make_fx proxy tensor tracer
Labels: triaged, module: fx

### 🐛 Describe the bug

`torch.fx.wrap` is used to create a "leaf function" that will be preserved as a `call_function` node in the FX trace instead of being
traced through. However, it works only with `torch.fx.symbolic_trace`.

```py
import torch
from torch.fx.experimental.proxy_tensor import make_fx

M = N = K = 32
a = torch.randn(M, K, device="cuda", dtype=torch.float16)
b = torch.randn(N, K, device="cuda", dtype=torch.float16)
bias = torch.randn(N, device="cuda", dtype=torch.float16)

@torch.fx.wrap # doesn't work with make_fx!
def my_gelu(x):
    return torch.nn.functional.gelu(x)

def func(a, b, bias):
    linear = torch.nn.functional.linear(a, b, bias=bias)
    y = my_gelu(linear)
    return y

gm = make_fx(func)(a, b, bias)
gm.graph.print_tabular()
# opcode         name    target              args              kwargs
# -------------  ------  ------------------  ----------------  --------
# placeholder    a_1     a_1                 ()                {}
# placeholder    b_1     b_1                 ()                {}
# placeholder    bias_1  bias_1              ()                {}
# call_function  t       aten.t.default      (b_1,)            {}
# call_function  addmm   aten.addmm.default  (bias_1, a_1, t)  {}
# call_function  gelu    aten.gelu.default   (addmm,)          {}  # Should be "my_gelu" function here!
# output         output  output              (gelu,)           {}
```

The current alternative to make `make_fx` not trace through custom functions is to create a custom `torch.library.Library` with `CompositeExplicitAutograd` dispatch key. This alternative is much more complicated than using `fx.wrap`.

### Versions

master branch.

cc @ezyang @SherlockNoMad @soumith @EikanWang @jgong5 @wenzhe-nrv
Edge case: torch.baddbmm supports double x int8 x int8 inputs on CPU but not CUDA
Labels: triaged, module: type promotion, module: linear algebra, module: edge cases

### 🐛 Describe the bug


Test on the CPU:
          
              import torch
              input = torch.rand([], dtype=torch.float64)
              batch1 = torch.randint(-2, 128, [10, 3, 4], dtype=torch.int8)
              batch2 = torch.randint(-8, 128, [10, 4, 5], dtype=torch.int8)
              out = torch.baddbmm(input, batch1, batch2)
              print(out)
          
result:RuntimeError: expected scalar type Char but found Double
          

Test on the GPU:
          
              import torch
              input = torch.rand([], dtype=torch.float64).cuda()
              batch1 = torch.randint(-2, 128, [10, 3, 4], dtype=torch.int8).cuda()
              batch2 = torch.randint(-8, 128, [10, 4, 5], dtype=torch.int8).cuda()
              out = torch.baddbmm(input, batch1, batch2)
              print(out)

result: RuntimeError: expected scalar type Double but found Char


torch.baddbmm behaves differently in different pytorch versions. First, in pytorch1.8, the exceptions thrown by the CPU and GPU are completely opposite; 

### Versions

pytorch: 1.8
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows

cc @nairbv @mruberry @jianyuh @nikitaved @pearu @walterddr @IvanYashchuk @xwang233 @Lezcano
torch.equal can still run successfully when the parameter types are different.
Labels: triaged, module: numpy, module: type promotion

### 🐛 Describe the bug

Test on the CPU:

    import torch
    input = torch.rand([5, 5], dtype=torch.float64)
    other = torch.rand([5, 5], dtype=torch.complex64)
    out = torch.equal(input, other)
    print(out)

result: RuntimeError: Expected object of scalar type double but got scalar type struct c10::complex<float> for argument 'other'


Test on the GPU:

    import torch
    input = torch.rand([5, 5], dtype=torch.float64).cuda()
    other = torch.rand([5, 5], dtype=torch.complex64).cuda()
    out = torch.equal(input, other)
    print(out)

result: False

Although the two parameters input and other of torch.equal are both of Tensor type, but input is of double type and other is of complex type, but when running on the GPU, it gets False. According to understanding, an exception should be thrown.




### Versions

pytorch: 1.8
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows

cc @mruberry @rgommers @nairbv
torch.floor_divide: The dividend of torch.floor_divide is set to 0, but it can still run on the GPU.
Labels: module: error checking, triaged

### 🐛 Describe the bug

Test on the GPU:

    import torch
    input = torch.randint(2, 8, [1, 8], dtype=torch.int64)
    other = 0
    out = torch.floor_divide(input, other)
    print(out)

result: RuntimeError: ZeroDivisionError


Test on the GPU:

    import torch
    input = torch.randint(2, 8, [1, 8], dtype=torch.int64).cuda()
    other = 0
    out = torch.floor_divide(input, other)
    print(out)

result: RuntimeError: tensor([[4294967295, 4294967295, 4294967295, 4294967295, 4294967295, 4294967295, 4294967295, 4294967295]], device='cuda:0')

The dividend of torch.floor_divide is set to 0, but it can still run on the GPU.

### Versions

pytorch: 1.8
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows
When the torch.masked_select operator passes in the same parameters, it behaves differently on CPU and GPU.
Labels: triaged, module: masked operators

### 🐛 Describe the bug

Test on the CPU:

    import torch
    input = torch.rand([], dtype=torch.float64)
    out = torch.logcumsumexp(input, dim=1)
    print(out)

result: IndexError: Dimension out of range (expected to be in range of [-1, 0], but got 1)


Test on the CPU:

    import torch
    input = torch.rand([], dtype=torch.float64).cuda()
    out = torch.logcumsumexp(input, dim=1)
    print(out)

result: IndexError: tensor(0.4230, device='cuda:0', dtype=torch.float64)

When the torch.masked_select operator passes in the same parameters, it behaves differently on CPU and GPU.

### Versions

pytorch: 1.12.1
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows
torch.nn.MultiLabelMarginLoss has different performance on CPU and GPU.
Labels: module: loss, triaged

### 🐛 Describe the bug

Test on the CPU:

    import torch
    loss = torch.nn.MultiLabelMarginLoss()
    x = torch.randn((1, 4))
    y = torch.randint(4, 16, [1, 4])
    out = loss(x, y)
    print(out)

result: RuntimeError: argument #2 'target' is out of range


Test on the GPU:

    import torch
    loss = torch.nn.MultiLabelMarginLoss().cuda()
    x = torch.randn((1, 4)).cuda()
    y = torch.randint(4, 16, [1, 4]).cuda()
    out = loss(x, y)
    print(out)

result: tensor(5.7001, device='cuda:0')

torch.nn.MultiLabelMarginLoss has different performance on CPU and GPU.

### Versions

pytorch: 1.12.1
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.3
GPU models and configuration: RTX3060
Operating System：Windows
[MPS] Using unsqueeze in inference mode returns anomalous result
Labels: triaged, inference mode, module: mps

### 🐛 Describe the bug

Using unsqueeze in inference mode returns anomalous result.
..It may looks no problem, but it will negatively affect later processing.

```python
@torch.inference_mode() # required
def cake():
    mps = torch.device("mps")
    a = torch.arange(5, device = mps)
    test_idx = 1 # 1..*
    assert torch.equal(
        a[test_idx].unsqueeze(0),
        a[test_idx].cpu().unsqueeze(0).to(mps)
    )
cake()
```

```
Traceback (most recent call last):
  File "/test.py", line 17, in <module>
    cake()
  File "/opt/homebrew/Caskroom/miniconda/base/envs/test/lib/python3.10/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
    return func(*args, **kwargs)
  File "/test.py", line 13, in cake
    assert torch.equal(
AssertionError
```

### Versions

```
PyTorch version: 1.14.0.dev20221119
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.6 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.102)
CMake version: version 3.24.2
Libc version: N/A

Python version: 3.10.6 (main, Oct  7 2022, 15:17:36) [Clang 12.0.0 ] (64-bit runtime)
Python platform: macOS-12.6-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.4
[pip3] torch==1.14.0.dev20221119
[pip3] torchvision==0.15.0.dev20221119
[conda] numpy                     1.23.4                   pypi_0    pypi
[conda] torch                     1.14.0.dev20221119          pypi_0    pypi
[conda] torchvision               0.15.0.dev20221119          pypi_0    pypi
```

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
torch.nn.TransformerEncoderLayer missing exception description information.
Labels: module: nn, module: error checking, triaged, oncall: transformer/mha

### 🐛 Describe the bug

    import torch
    encoder_layer = torch.nn.TransformerEncoderLayer(d_model=52, nhead=1)
    src = torch.rand(10, 32, 512)
    out = encoder_layer(src)

When running this code, an AssertionError is thrown directly without giving effective information about the exception. The real error is that d_model is not equal to the third value in src. It is recommended to use the pytorch1.8.0 version. When this happens, throw Display the corresponding exception information.

### Versions

pytorch: 1.8.0
Python version: 3.8
CUDA/cuDNN version: cuDNN 11.1
GPU models and configuration: RTX3060
Operating System：Windows

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are @bhosmer @cpuhrsch @erichan1