gopikrsmscs/torch-issues huggingface dataset:
[inductor] `triton.runtime.jit` does not provide `get_cuda_stream`
Labels: triaged, oncall: pt2, module: inductor

### 🐛 Describe the bug

Installing and using newer versions of Triton (either from master or from the `triton-mlir` branches) with Python 3.10 fails with an `ImportError` due to https://github.com/pytorch/pytorch/blob/94262efc7d381ace82aa74ed2f5f5ec76f8fca95/torch/_inductor/triton_ops/autotune.py#L27

`triton.runtime.jit` doesn't seem to make that symbol available. Instead, they use an `import as` to get a function of that same name from `torch` (this line is consistent across `master`, `legacy-backend`, and the new `triton-mlir` branch): https://github.com/openai/triton/blob/899bb0a0e7592612300913179d1a7d5baf5d4db5/python/triton/runtime/jit.py#L19

Inductor's codeine wrapper does as well: https://github.com/pytorch/pytorch/blob/94262efc7d381ace82aa74ed2f5f5ec76f8fca95/torch/_inductor/codegen/wrapper.py#L289

Should `autotune.py` be changed to match?

### Versions

```text
Collecting environment information...
PyTorch version: 2.0.0a0+git77c2a8a
Is debug build: False
CUDA used to build PyTorch: 11.8
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: 16.0.0 (++20230106042333+ea0cd51a4958-1~exp1~20230106042433.666)
CMake version: version 3.25.0
Libc version: glibc-2.35

Python version: 3.10.9+ (8af15cf:8af15cf, Jan  6 2023, 18:00:43) [Clang 16.0.0 (++20230106042333+ea0cd51a4958-1~exp1~20230106042433.666)] (64-bit runtime)
Python platform: Linux-6.0.15-300.fc37.x86_64-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 11.8.89
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 4090
Nvidia driver version: 525.60.13
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.7.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.7.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.7.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.7.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.7.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.7.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.7.0
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.24.0
[pip3] torch==2.0.0a0+git77c2a8a
[pip3] torchvision==0.15.0a0+32d254b
[conda] Could not collect
```

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh @mlazos @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
Better API for `torch.cov` (and `Tensor.cov`)
Labels: feature, triaged, module: python frontend

### 🚀 The feature, motivation and pitch

Currently, the `cov` computes the mean internally and there is no way to reduce the computation if the mean is pre-computed/known or required alongside the covariance.

Potential new API (in Python):

```py
x = torch.rand(4,4)
m = x.mean()
c = x.cov(mean=m) 
```

```py
x = torch.rand(4,4)
c, m = x.cov_and_mean()
```

### Alternatives

_No response_

### Additional context

[Doc](https://pytorch.org/docs/master/generated/torch.cov.html#torch.cov)

cc @albanD
Codegen for in_out_ptr seems suboptimal
Labels: triaged, oncall: pt2, module: inductor

### 🐛 Describe the bug

When compiling the forward of hfBert, the following kernel is generated under the name of
```
triton_fused_add_97_convert_element_type_134_getitem_49_rsqrt_24_var_mean_24_view_228_40 
```

```python
@triton.jit
def triton_(in_out_ptr0, in_out_ptr1, in_out_ptr2, seed0, in_ptr1, in_ptr2, in_ptr3, out_ptr1, xnumel, rnumel, XBLOCK : tl.constexpr, RBLOCK : tl.constexpr):
    xnumel = 8192
    rnumel = 768
    xoffset = tl.program_id(0) * XBLOCK
    xindex = xoffset + tl.reshape(tl.arange(0, XBLOCK), [XBLOCK, 1])
    xmask = xindex < xnumel
    rbase = tl.reshape(tl.arange(0, RBLOCK), [1, RBLOCK])
    tmp0 = tl.load(seed0 + (0 + tl.zeros([XBLOCK, RBLOCK], tl.int32)), None)
    x0 = xindex
    for roffset in range(0, rnumel, RBLOCK):
        rindex = roffset + rbase
        rmask = rindex < rnumel
        r1 = rindex
        tmp6 = tl.load(in_out_ptr0 + (r1 + (768*x0)), rmask & xmask, eviction_policy='evict_last').to(tl.float32)
        tmp10 = tl.load(in_ptr1 + (r1 + (768*x0)), rmask & xmask, eviction_policy='evict_last').to(tl.float32)
        tmp1 = 754974720 + r1 + (768*x0)
        tmp2 = tl.rand(tmp0, tmp1)
        tmp3 = 0.1
        tmp4 = tmp2 > tmp3
        tmp5 = tmp4.to(tl.float32)
        tmp7 = tmp5 * tmp6
        tmp8 = 1.1111111111111112
        tmp9 = tmp7 * tmp8
        tmp11 = tmp9 + tmp10
        tl.store(in_out_ptr0 + (r1 + (768*x0) + tl.zeros([XBLOCK, RBLOCK], tl.int32)), tmp11, rmask & xmask)
    _tmp14 = tl.zeros([XBLOCK, RBLOCK], tl.float32) + 0
    for roffset in range(0, rnumel, RBLOCK):
        rindex = roffset + rbase
        rmask = rindex < rnumel
        r1 = rindex
        tmp12 = tl.load(in_out_ptr0 + (r1 + (768*x0)), rmask & xmask, eviction_policy='evict_last').to(tl.float32)
        tmp13 = tmp12.to(tl.float32)
        _tmp14 = tl.where(xmask & rmask, _tmp14 + tmp13, _tmp14)
...
```
Those two for loops could be fused into one saving the load of `in_out_ptr0` (we would still need to store it as it's used later on though.

### Versions

master

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh @mlazos @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
Inconsistent rank among torch.distributed primitives
Labels: oncall: distributed, triaged

### 🐛 Describe the bug

Currently, the distributed communication primitives under `torch.distributed` enforce some checks on each worker's rank and their corresponding arguments passed. There exist many `my_rank=get_rank()` in [distributed_c10d.py].(https://github.com/pytorch/pytorch/blob/ad782ff7df950dfda64e271dd4ee3c6128971103/torch/distributed/distributed_c10d.py)

The following is an example.
https://github.com/pytorch/pytorch/blob/8c172fa98a52e95675e9425ac4b23f190f53f9ed/torch/distributed/distributed_c10d.py#L2315-L2321

It seems strange that there are many widely-used primitives forces using `global_rank` even when `group` is specified. For example, the `dist.gather`. 
https://github.com/pytorch/pytorch/blob/8c172fa98a52e95675e9425ac4b23f190f53f9ed/torch/distributed/distributed_c10d.py#L2674-L2676

The `get_rank()` above without an argument `group` passed will return the `global_rank` of the caller worker, which is different from the above. 
 
I am wondering if it is a bug or if there is any documentation on using `global_rank` only in these primitives. 

### Versions

current master ad782ff7df950dfda64e271dd4ee3c6128971103

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
CUDA error: initialization error
Labels: module: cuda, triaged, module: regression, module: nvfuser

### 🐛 Describe the bug

Consider the following code.

```python
from multiprocessing import Process
import os
import torch

print(torch.__version__)

@torch.jit.script
def distance_classification():
    return "distance_classification"

class X(torch.nn.Module):
    x = distance_classification()


def train_on_node():
    print(f"XXXXXYYYYZZZZ 3 pid={os.getpid()}")
    torch._C._cuda_init()
    print(f"XXXXXYYYYZZZZ 4 pid={os.getpid()}")
    return 123

p = Process(target=train_on_node, args=())
p.start()
p.join()
```

On PyTorch 1.11 it executed without a problem:
```
1.11.0+cu102
XXXXXYYYYZZZZ 3 pid=3739
XXXXXYYYYZZZZ 4 pid=3739
```

On PyTorch 1.12.0 it throws this error
```
1.12.0+cu102
XXXXXYYYYZZZZ 3 pid=2660
Process Process-1:
Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "<ipython-input-1-7de82f15ef1a>", line 17, in train_on_node
    torch._C._cuda_init()
RuntimeError: !in_bad_fork INTERNAL ASSERT FAILED at "../torch/csrc/cuda/Module.cpp":587, please report a bug to PyTorch. 
```

On PyTorch 1.13.0 it throws this error
```
1.13.0+cu117
XXXXXYYYYZZZZ 3 pid=4944
Process Process-1:
Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "<ipython-input-1-7de82f15ef1a>", line 17, in train_on_node
    torch._C._cuda_init()
RuntimeError: CUDA error: initialization error
CUDA kernel errors might be asynchronously reported at some other API call,so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1.
```

I'd like to understand if is this a regression or intended behavior. If it's intended behavior, what would be a recommendation to fix it in our user code?

### Versions

1.13.0
1.12.0

cc @ngimel @kevinstephano @jjsjann123
SymIntType gets translated to int when going through pybind
Labels: triaged, oncall: pt2, module: dynamic shapes

```
import torch
print(torch.ops.aten.sym_size.int._schema)
print(torch.ops.aten.sym_size.int._schema.returns[0].type)
```
produces:
```
aten::sym_size.int(Tensor self, int dim) -> SymInt
int
```
I would expect the second line to be `torch.SymInt`. Somewhere something is going funky, although it seems the binding for `SymInt` has been properly done here: https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/python/python_ir.cpp#L996

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
[bazel] replace //c10:headers dependency by //c10 dependency
Labels: triaged, module: bazel

### 🐛 Describe the bug

Follow-up from https://github.com/pytorch/pytorch/pull/91422

As @dagitses pointed out, there is no real reason to make the `//c10:headers` public, if they are available on the `//c10`.
Currently they are not as demonstrated by the following bazel queries

```
sergei.vorobev@cs-7xn77uoy-gpu-homedir-848671:~/workspaces/c2/src/github.robot.car/cruise/cruise$ bazel query 'somepath(@pytorch//c10, @pytorch//c10:headers)'
WARNING: build volume is nearly full (104.165 GB remain). Free up space to avoid running out of disk!

INFO: Invocation ID: ddea5aba-8c65-11ed-b684-42010ad8716a
INFO: Empty results
Loading: 18 packages loaded
sergei.vorobev@cs-7xn77uoy-gpu-homedir-848671:~/workspaces/c2/src/github.robot.car/cruise/cruise$ bazel query 'somepath(@pytorch//c10:headers, @pytorch//c10)'
WARNING: build volume is nearly full (104.165 GB remain). Free up space to avoid running out of disk!

INFO: Invocation ID: e3970a9e-8c65-11ed-b684-42010ad8716a
INFO: Empty results
Loading: 0 packages loaded
```

This issue it to track the unification of this bazel build aspect: to expose the headers on the lib target.

### Versions

master
[MPS] Improve the performance of torch.linear()
Labels: triaged, enhancement, module: backend, module: mps

The MPS's linear operation uses the temporary workaround #91114 to improve the performance. 
However, that workaround is limited to specific tensor sizes. With the upcoming Ventura updates, a more generic fix will be available that would optimize MatMul ops for a wider range of tensor sizes. 
I'm creating this issue to track the progress of MatMul optimizations, and also as a reminder to remove the workaround in torch.linear() once the generic solution becomes available.

cc @kulinseth @albanD @malfet @DenisVieriu97 @abhudev
linspace (and arange) behaves differently on GPU and CPU
Labels: triaged

### 🐛 Describe the bug

There seems to be numerical inconsistencies when `torch.linspace` is run on GPU vs on CPU, especially when the step size isn't an integer. This difference becomes more obvious when other operations are performed downstream, such as sine and cosine.

The following example can also be reproduced on Google Colab's GPU runtime.

```python
import numpy as np
import torch
from matplotlib import pyplot as plt

n = 200
start, end = -100, 100
device = "cuda"
a = torch.linspace(start, end, steps=n).to(device="cuda")
b = torch.linspace(start, end, steps=n, device="cuda")
print(torch.allclose(a, b))                 # this is True, as expected
print(torch.allclose(a.sin(), b.sin()))     # this is False, the error becomes non-negligible

# plot error against array index
plt.scatter(np.arange(n), (a - b).cpu().numpy())
plt.show()
```

The same issue also exists for `torch.arange`:

```python
import numpy as np
import torch
from matplotlib import pyplot as plt

start, end = -100, 100
step_size = np.random.rand() * 10
device = "cuda"

c = torch.arange(start, end, step=step_size).to(device="cuda")
d = torch.arange(start, end, step=step_size, device="cuda")
print(torch.allclose(c, d))                 # this is mostly True, as expected
print(torch.allclose(c.sin(), d.sin()))     # this is False, the error becomes non-negligible

# plot error against array index
plt.scatter(np.arange(len(c)), (c - d).cpu().numpy())
plt.show()
```

### Versions

Collecting environment information...
PyTorch version: 1.13.0+cu116
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.6
Libc version: glibc-2.27

Python version: 3.8.16 (default, Dec  7 2022, 01:12:13)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.133+-x86_64-with-glibc2.27
Is CUDA available: True
CUDA runtime version: 11.2.152
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: Tesla T4
Nvidia driver version: 460.32.03
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.13.0+cu116
[pip3] torchaudio==0.13.0+cu116
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.14.0
[pip3] torchvision==0.14.0+cu116
[conda] Could not collect
Add vmap support for torch.linalg.vander
Labels: good first issue, triaged, module: functorch

## Tasks
Add vmap support for the following PyTorch operations. That is, each one needs a batching rule.
- [ ] torch.linalg.vander

## Expected behavior
Currently, when one does vmap over them, they raise a warning suggesting the batching rule is not implemented:
```py
import torch
from functorch import vmap
x = torch.randn(4, 3, 2)
z = vmap(torch.linalg.vander)(x)
#  UserWarning: There is a performance drop because we have not yet implemented the batching rule
```
We expect to not see a warning

## Read this!

See this note for more context https://github.com/pytorch/pytorch/blob/master/functorch/writing_batching_rules.md

If you're new to developing PyTorch and/or function transforms, we would recommend reading through https://github.com/pytorch/pytorch/wiki/Core-Frontend-Onboarding#unit-8-function-transforms-optional

Should likely be similar to the `view_as_complex` operator here
https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/functorch/BatchRulesUnaryOps.cpp#L64-L72
using the macro here
https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/functorch/BatchRulesUnaryOps.cpp#L94

Please reach out on this issue if there's any questions!

## Testing

`pytest test/functorch/test_vmap.py -v -k "op_has_batch_rule and vander"` should pass (currently, it is an expected failure).


cc @zou3519 @Chillee @soumith
[discussion] Analyzing a list of tensors stored as intermediate values / saved_for_backward in autograd graph
Labels: module: autograd, good first issue, triaged, actionable

### 🚀 The feature, motivation and pitch

It's useful for understanding memory usage and if memory can be saved by refatoring to fusion + inplace

The parent issue would be https://github.com/pytorch/pytorch/issues/1529, here's the scope is only on stored intermediate values in autograd graph.

But overall, being able to get a list of all tensors and storages currently allocated (including from C++) is very useful for simple form of memory profiling (even ignoring possible memory overlaps / views etc)

E.g. it would be interesting to compare theses lists for vanilla fp32 TransformerEncoder, autocast+bf16 TransformerEncoder, autocast+fp16 TransformerEncoder, BetterTransformer / efficient_attention / flash_attention variants of TransformerEncoder. This utility should also clearly demonstrate the effect of activation checkpointing / CPU offloading techniques; Reversible Transformers / Reversible ConvNets and would be very useful for pedagogical use and debugging

Some previous discussion: https://discuss.pytorch.org/t/memory-size-of-all-tensors-referenced-by-autograd-graph/169227/4

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Wrong in building torch from source
Labels: triaged

### 🐛 Describe the bug

When I build torch-v1.12.1 from source, there is something wrong "caffe2/CMakeFiles/torch_cuda.dir/__/torch/csrc/distributed/c10d/quantization/quantization_gpu.cu.o No such file or directory"
and the compile failed..



### Versions

Version: 1.12.1

CUDA 10.2  (nvidia-smi)
CUDA: 10.2.89 (nvcc)
CUDNN: 7.6.5

GCC/G++:7.5.0
AssertionError: tensor's device must be `meta` when trying to export a fake-initialized module
Labels: triaged, module: fakeTensor

```
import torch
from torch._dynamo import export
from torch._subclasses import FakeTensorMode

class JankyLinear(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.out_features = torch.nn.Parameter(torch.randn([512, 1677]))
        self.bias = torch.nn.Parameter(torch.randn([512]))

    def forward(self, input):
        return torch.nn.functional.linear(input, self.out_features, bias=self.bias)

# initialize a module in fake tensor mode
with FakeTensorMode():
        j = JankyLinear()
        j.cuda()

# try to export it
export(j, torch.randn([512, 1677]).cuda())
```
This raises:
```
AssertionError: tensor's device must be `meta`, got cuda instead
```

Which is strange, as all the tensors are clearly FakeTensors. Seems like a decomp generates some intermediate that is tripped an internal assert.
[FSDP][BE] Add check that compute device equals current device
Labels: oncall: distributed, triaged, module: fsdp

The FSDP implementation requires that the [current device](https://pytorch.org/docs/stable/generated/torch.cuda.current_device.html) be equal to `FullyShardedDataParallel.compute_device` and `FlatParamHandle.device`. Otherwise, on nonzero ranks, there will be an error in `FlatParamHandle.post_unshard()` at:
https://github.com/pytorch/pytorch/blob/57b7f33ba8bfca7918f78aef7dc8d1d63198510b/torch/distributed/fsdp/flat_param.py#L1007
This results from `padded_unsharded_flat_param[:unsharded_size.numel()]` returning a tensor on `cuda:0` instead of `cuda:n` for `n > 1`, despite `padded_unsharded_flat_param` correctly being on `cuda:n`.

https://github.com/pytorch/pytorch/blob/57b7f33ba8bfca7918f78aef7dc8d1d63198510b/torch/distributed/fsdp/flat_param.py#L982-L984

We should add a check at construction time that the current device is set to ensure that CUDA tensors are constructed on the correct device. 



cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501
FakeTensors not moving between device properly on Module.cuda()
Labels: triaged, module: fakeTensor

```
from torch._subclasses import FakeTensorMode

class MyModule(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.param = torch.nn.Parameter(torch.empty([10]).fill_(1.0))

with FakeTensorMode():
    foo = MyModule()

print(foo.param)
foo.cuda()
print(foo.param)
```

both print statements show `param` on cpu.

Some cursory debugging shows that the issue is the setting of `data` here: https://github.com/pytorch/pytorch/blob/master/torch/nn/modules/module.py#L809-L811. If I add:
```
torch.__future__.set_overwrite_module_params_on_conversion(True)
```
to get the new behavior, things work correctly.
Segmentation fault when running torch.nn.functional.fractional_max_pool3d on torch 1.13.1
Labels: needs reproduction, module: crash, triaged

### 🐛 Describe the bug

With the following input combinations, it results in segfault:
```
import torch
import numpy as np
arg_1_tensor = torch.rand([2, 4, 5, 5, 5], dtype=torch.float64)
arg_1 = arg_1_tensor.clone()
arg_2_0 = 2
arg_2_1 = 2
arg_2_2 = 2
arg_2 = [arg_2_0,arg_2_1,arg_2_2,]
arg_3 = None
arg_4_0 = 0.5
arg_4_1 = 0.5
arg_4_2 = 0.5
arg_4 = [arg_4_0,arg_4_1,arg_4_2,]
arg_5 = False
arg_6_tensor = torch.tensor([], dtype=torch.float64)
arg_6 = arg_6_tensor.clone()
try:
  res = torch.nn.functional.fractional_max_pool3d(arg_1,arg_2,arg_3,arg_4,arg_5,_random_samples=arg_6,)
except Exception as e:
  print("Error:"+str(e))
```

### Versions

PyTorch version: 1.13.1
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.35

Python version: 3.9.15 (main, Nov 24 2022, 14:31:59) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-56-generic-x86_64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: 11.6.124
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.5
[pip3] torch==1.13.1
[pip3] torchaudio==0.13.1
[pip3] torchvision==0.14.1
[conda] blas 1.0 mkl
[conda] ffmpeg 4.3 hf484d3e_0 pytorch
[conda] mkl 2021.4.0 h06a4308_640
[conda] mkl-service 2.4.0 py39h7f8727e_0
[conda] mkl_fft 1.3.1 py39hd3c417c_0
[conda] mkl_random 1.2.2 py39h51133e4_0
[conda] numpy 1.23.5 py39h14f4228_0
[conda] numpy-base 1.23.5 py39h31eccc5_0
[conda] pytorch 1.13.1 py3.9_cuda11.6_cudnn8.3.2_0 pytorch
[conda] pytorch-cuda 11.6 h867d48c_1 pytorch
[conda] pytorch-mutex 1.0 cuda pytorch
[conda] torchaudio 0.13.1 py39_cu116 pytorch
[conda] torchvision 0.14.1 py39_cu116 pytorch
Periodic ROCM distribtued jobs are broken
Labels: module: rocm, triaged

### 🐛 Describe the bug

See https://hud.pytorch.org/hud/pytorch/pytorch/master/1?per_page=50&name_filter=periodic%20%2F%20linux-focal-rocm

Last successful run was on Dec 16th: https://hud.pytorch.org/pytorch/pytorch/commit/bd94ee66ea361e97158d37d6ddd8dbbeb8b624ef

### Versions

CI

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport
Investigate CUDA enabled build-time difference between MSVC and GCC+WSL
Labels: module: build, module: windows, triaged

From preliminary investigation results, it seems that build time when CUDA is enabled is three times longer with MSVC than with GCC on WSL on the same hardware. Within this issue, we should investigate what is the cause and suggest possible solution.

cc @malfet @seemethere @peterjc123 @mszhanyi @skyline75489 @nbcsm
Cross-compiled libtorch Windows Arm64 binaries
Labels: module: windows, feature, module: ci, triaged, module: arm

Nightly CD pipelines should build Debug and Release libtorch binaries for Windows ARM64 platform cross-compiling using x64 runners.

cc @peterjc123 @mszhanyi @skyline75489 @nbcsm @seemethere @malfet @pytorch/pytorch-dev-infra
There is no developer documentation about getting started with MPS native debugging
Labels: module: docs, triaged, module: mps

### 📚 The doc issue

per title - getting started with writing native MPS code, or even tracking down bugs, assumes a large amount of pre-existing knowledge, and requires a lot of trial and error, because there's no documentation.

### Suggest a potential alternative/fix

I have already [written an informal guide/devlog](https://medium.com/p/f094b7f4e8f0) about what I had to do to be able to break into an LLDB session inside ATen MPS native code. I'd be very happy to adapt it for inclusion here, but I'd like to get approval from whomever is responsible for docs on the PyTorch team before going ahead.

cc @svekars @carljparker @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
wrong assert message
Labels: oncall: quantization, triaged

https://github.com/pytorch/pytorch/blob/cce577b39154b501705f32ee0392c77eee43820b/torch/ao/quantization/utils.py#L357-L359

In the assert condition, `2**31` is used, which is `2**31 = 2147483648`

However, in the error message, `4294967296` is used, which is `2**32 = 4294967296`

I think the assert message is wrong.

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
vmap + nn.SyncBatchNorm.convert_sync_batchnorm
Labels: oncall: distributed, module: data parallel, module: ddp, module: functorch

I ran into this problem with `vmap` and `functorch`.  I am currently trying out different parallelization schemes, i.e. `dataparallel` and `distributeddataparallel`. `vmap` and `functorch` work fine when I use `model= nn.DataParallel(model)`, but when I use `distributeddataparallel` the error mentioned in pytorch/functorch#867 comes up again (specifically [this](https://github.com/pytorch/functorch/issues/867#issuecomment-1154273349), which was then fixed in pytorch/functorch#958 ), despite the fact that the model is in `.eval()` mode. To apply a quick fix, I used `replace_all_batch_norm_modules_` to patch the batchnorms, but then received this error
`
RuntimeError: functorch functions (vmap, grad, vjp, etc.) currently do not support the use of autograd.Function. Please rewrite your function to not use autograd.Function while we work on fixing this
`
I am not sure what this error implies/means, but my hunch (which might very well be wrong) is that the problem is coming from `model = nn.SyncBatchNorm.convert_sync_batchnorm(model)` that is required for `distributeddataparallel`. Do you have any suggested quick fix or am I making mistakes somewhere?

(I asked the same question in pytorch/functorch#958 at [here](https://github.com/pytorch/functorch/pull/958#issuecomment-1369177208))

EDIT: potentially similar discussion pytorch/functorch#207 

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @zou3519 @Chillee @samdow @soumith
`mul(CSC, CSC)` fails with layout mismatch between the inputs and the output.
Labels: module: sparse, triaged

### 🐛 Describe the bug

```python
In [1]: import torch

In [2]: x = torch.rand(3, 3).to_sparse_csr()
<ipython-input-2-a111f877c399>:1: UserWarning: Sparse CSR tensor support is in beta state. If you miss a functionality in the sparse tensor support, please submit a feature request to https://github.com/pytorch/pytorch/issues. (Triggered internally at /home/nik/git/Quansight/pytorch/aten/src/ATen/SparseCsrTensorImpl.cpp:54.)
  x = torch.rand(3, 3).to_sparse_csr()

In [3]: x * x
Out[3]: 
tensor(crow_indices=tensor([0, 3, 6, 9]),
       col_indices=tensor([0, 1, 2, 0, 1, 2, 0, 1, 2]),
       values=tensor([0.7678, 0.0257, 0.1134, 0.4288, 0.0411, 0.0229, 0.3167,
                      0.1143, 0.1028]), size=(3, 3), nnz=9,
       layout=torch.sparse_csr)

In [4]: x_csc = x.to_sparse_csc()

In [5]: x_csc * x_csc
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
Input In [5], in <cell line: 1>()
----> 1 x_csc * x_csc

RuntimeError: Expected result Tensor to be of format CSR

```

### Versions

Current master.

cc @pearu @cpuhrsch @amjames @bhosmer
Division by zero error when running torch.nn.functional.lp_pool1d
Labels: triaged, module: edge cases

### 🐛 Describe the bug

When I run torch.nn.functional.lp_pool1d with second argument as zero, it results in division by zero
```
import torch
import numpy as np
arg_1_tensor = torch.rand([3, 7], dtype=torch.float64)
arg_1 = arg_1_tensor.clone()
arg_2 = 0
arg_3 = 2
arg_4 = 3
arg_5 = False
try:
  res = torch.nn.functional.lp_pool1d(arg_1,arg_2,arg_3,arg_4,arg_5,)
except Exception as e:
  print("Error:"+str(e))
```

The log message is:

```
Error:float division by zero

```

### Versions

PyTorch version: 1.12.0
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.35

Python version: 3.9.15 (main, Nov 24 2022, 14:31:59) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-56-generic-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to:
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1660 Ti
Nvidia driver version: 525.60.11
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.5
[pip3] torch==1.12.0
[pip3] torchaudio==0.12.0
[pip3] torchvision==0.13.0
[conda] blas 1.0 mkl
[conda] cudatoolkit 11.3.1 h2bc3f7f_2
[conda] ffmpeg 4.3 hf484d3e_0 pytorch
[conda] mkl 2021.4.0 h06a4308_640
[conda] mkl-service 2.4.0 py39h7f8727e_0
[conda] mkl_fft 1.3.1 py39hd3c417c_0
[conda] mkl_random 1.2.2 py39h51133e4_0
[conda] numpy 1.23.5 py39h14f4228_0
[conda] numpy-base 1.23.5 py39h31eccc5_0
[conda] pytorch 1.12.0 py3.9_cuda11.3_cudnn8.3.2_0 pytorch
[conda] pytorch-mutex 1.0 cuda pytorch
[conda] torchaudio 0.12.0 py39_cu113 pytorch
[conda] torchvision 0.13.0 py39_cu113 pytorch
Crashes of linalg.ldl_solve on different edge cases not coming from linalg.ldl_factor
Labels: module: crash, triaged, module: linear algebra, module: edge cases

## Double free on negative indices on CPU

```python
import torch
import numpy as np
arg_1_tensor = torch.neg(torch.rand([4, 5, 5], dtype=torch.float32))
arg_1 = arg_1_tensor.clone()
arg_2_tensor = torch.randint(-2048,1,[4, 5], dtype=torch.int32)
arg_2 = arg_2_tensor.clone()
arg_3_tensor = torch.rand([4, 5, 1], dtype=torch.float32)
arg_3 = arg_3_tensor.clone()
arg_4 = False
try:
  res = torch.linalg.ldl_solve(arg_1,arg_2,arg_3,hermitian=arg_4,)
except Exception as e:
  print("Error:"+str(e))
```

## Segfault on neg + CPU

```python
import torch
import numpy as np
arg_1_tensor = torch.neg(torch.rand([2, 2, 5, 5], dtype=torch.complex64))
arg_1 = arg_1_tensor.clone()
arg_2_tensor = torch.randint(-128,512,[2, 2, 5], dtype=torch.int32)
arg_2 = arg_2_tensor.clone()
arg_3_tensor = torch.rand([2, 2, 5, 1], dtype=torch.complex64)
arg_3 = arg_3_tensor.clone()
arg_4 = True
try:
  res = torch.linalg.ldl_solve(arg_1,arg_2,arg_3,hermitian=arg_4,)
except Exception as e:
  print("Error:"+str(e))
```
LBFGS wolfe exceeds the maximum allowed iterations
Labels: module: optimizer, triaged, actionable

### 🐛 Describe the bug

We can specify the maximum amount of evaluations lbfgs can use every step. It is passed by `max_eval`.
When using strong wolfe, a call to `_strong_wolfe` is made and return the amount of evaluations done during the call. After that, a condition is checked if the amount of evaluations is below `max_eval`. Note that if `max_eval=3`, `_strong_wolfe` can still run 25 iterations and return 25. In theory `_strong_wolfe` has a parameter `max_ls` to limit exactly that. But LBFGS doesn't pass it and return the default value of 25.
It makes `max_eval` inaccurate and for small values almost useless.

Interestingly, if you install `1.10.1+cu113` from `https://download.pytorch.org/whl/torch_stable.html` you can see a fix was done:
```python
                    loss, flat_grad, t, ls_func_evals = _strong_wolfe(
                        obj_func, x_init, t, d, loss, flat_grad, gtd, max_ls=min(25, max_eval - current_evals)
                    )
```
In version 1.12 we don't see the usage of `max_ls` and we see:
```python
                    loss, flat_grad, t, ls_func_evals = _strong_wolfe(
                        obj_func, x_init, t, d, loss, flat_grad, gtd)
```
I don't find any commit with the fix I mentioned above but somehow it was released and then reverted(?).
Moving to commit `302ee7bfb6` which is tagged as `1.10.1` doesn't show this change either.

### Versions

PyTorch version: 1.12.0+cu116
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.5 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: version 3.22.3
Libc version: glibc-2.31

Python version: 3.9.13 | packaged by conda-forge | (main, May 27 2022, 16:56:21)  [GCC 10.3.0] (64-bit runtime)
Python platform: Linux-5.15.0-1019-aws-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: 
GPU models and configuration: GPU 0: NVIDIA A10G
Nvidia driver version: 510.73.08
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.0
[pip3] torch==1.12.0+cu116
[pip3] torch-model-archiver==0.5.3b20220226
[pip3] torch-workflow-archiver==0.2.4b20220513
[pip3] torchaudio==0.12.0
[pip3] torchfile==0.1.0
[pip3] torchserve==0.6.0b20220513
[pip3] torchtext==0.13.0
[pip3] torchvision==0.13.0
[conda] No relevant packages

cc @vincentqb @jbschlosser @albanD @janeyx99
[RFC] FP8 dtype introduction to PyTorch
Labels: oncall: quantization, triaged

### 🚀 The feature, motivation and pitch

Proposal of adding native fp8 dtypes in PyTorch.

Motivation and details in rfcs PR: https://github.com/pytorch/rfcs/pull/51

### Alternatives

_No response_

### Additional context

_No response_

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
Add BlockWise Distribution Support to the torch.distributions Package
Labels: module: distributions, triaged

### 🚀 The feature, motivation and pitch

I am requesting the addition of BlockWise distribution support to the torch.distributions package in PyTorch. By "BlockWise distribution", I am referring to distributions for which the event dimensions have separate, distinct and independent distributions.

For example, consider an n-dimensional event space, where each dimension is independently distributed according to a separate distribution. A BlockWise distribution would allow users to specify and sample from this type of distribution using the torch.distributions API.

This type of distribution can be useful in a variety of applications, such as factorizing a complex distribution into a product of simpler distributions, or modeling distributions over high-dimensional event spaces. The particular use case I have in mind is to create separate distributions for a radial and angular coordinate (say a MixtureSameFamily and a Uniform distribution to create multiple rings), then use a Transform (Bijector) to recover cartesian coordinates. 

It would be great if PyTorch could provide support for BlockWise distributions through the torch.distributions package.

Here is how my particular example would look like

```python
import numpy as np
import torch
import torch.distributions as tfd

def rings(modes: int = 4, mode_width: float = 0.1, inner_radius: float = 1., outer_radius = 10.):
    """
    Concentric rings distribution
        :param modes: Number of concentric rings in the mixture
        :param inner_radius: Size of the smallest ring.
        :param outer_radius: Size of the largest ring.
        :param mode_width: Width of the modes (radial coordinate only)
    """
    r = torch.linspace(inner_radius, outer_radius, modes)
    mixture = tfd.Categorical(probs=torch.ones(modes), validate_args=False)
    component = tfd.Normal(loc=r, scale=mode_width, validate_args=False)
    r_distribution = tfd.MixtureSameFamily(mixture, component, validate_args=False)
    theta_distribution = tfd.Uniform(low=-np.pi, high=np.pi, validate_args=False)
    return tfd.TransformedDistribution(
        base_distribution=tfd.BlockWise([r_distribution, theta_distribution]),
        transforms=PolarToCartesianTransform()
    )
``` 

Thank you for considering this feature request!






### Alternatives

_No response_

### Additional context

_No response_

cc @fritzo @neerajprad @alicanb @nikitaved
Security policy impractical / lacks contact information?
Labels: high priority, module: docs, triaged, security

### 📚 The doc issue

Hi, happy new year! :tada: 

I have a potential security issue to report but https://github.com/pytorch/pytorch/security/policy does not answer the question where to send reports to but only links to a page [Meta/Facebook(!) Bug Bounty Program Info](https://www.facebook.com/whitehat) with a wall of text and where it's not clear which parts applies to Meta/Facbook only and which to PyTorch. On a side note, I do not have a Facbook account. So this seems rather impractical, and I can now choose whether to (a) just report right to the public issue tracker or (b) not report at all. Please recondsider this approach, thank you! If you'd like to reach out off-GitHub, my profile has my e-mail address for contact.

Best, Sebastian

### Suggest a potential alternative/fix

_No response_

cc @ezyang @gchanan @zou3519 @svekars @carljparker
min/max not supported for Long dtype on MPS
Labels: triaged, module: mps

### 🐛 Describe the bug

```python
dev = torch.device('mps')
indices = torch.tensor([[0, 1, 2], [0, 1, 2]])
value = torch.tensor([1, 2, 3])
a = torch.sparse_coo_tensor(indices, value, (4, 4),
                            dtype=torch.float32,
                            device=dev).to_dense()
print(a)
```

```
RuntimeError                              Traceback (most recent call last)
Cell In [16], line 5
      3 indices = torch.tensor([[0, 1, 2], [0, 1, 2]])
      4 value = torch.tensor([1, 2, 3])
----> 5 a = torch.sparse_coo_tensor(indices, value, (4, 4),
      6                             dtype=torch.float32,
      7                             device=dev).to_dense()
      8 print(a)

RuntimeError: input_t.scalar_type() != ScalarType::Long INTERNAL ASSERT FAILED at "/Users/runner/work/pytorch/pytorch/pytorch/aten/src/ATen/native/mps/operations/ReduceOps.mm":1196, please report a bug to PyTorch. min/max not supported for Long dtype on MPS
```

### Versions

```
torch                        2.0.0.dev20221231
torchaudio               2.0.0.dev20221231
torchvision               0.15.0.dev20221231
```

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
`torch::jit::optimize_for_inference` doesn't preserve exported methods when calling `freeze`
Labels: oncall: jit

I came across this issue while trying to optimize a JIT scripted model from python in my C++ app. I'm developing against `libtorch==1.13.1` and using `torch==1.13.1` in python in the CUDA+cuDNN dev container. The model was converted with `torch.jit.script` and had an additional `torch.jit.export` exported method named "inference".

When trying to run `torch::jit::optimize_for_inference(model, {"inference"})` in my C++ app, I get an error saying:
```
terminate called after throwing an instance of 'c10::Error'
  what():  Method 'inference' is not defined.
```
This stems from the fact that during model optimization, the model is frozen but the vector `other_methods` is not passed into the `preserved_attrs` parameter of `freeze`. I don't have a full `libtorch` development environment set up but have written my own version of `optimize_for_inference` with the proposed change of `frozen_mod = freeze(module, other_methods, true);` and it appears to work well. If I have time/can get a dev environment set up before you all get to it, I'm happy to make a PR.

https://github.com/pytorch/pytorch/blob/77c2a8a11f7b5164c255b5b49dbc66a3f6533e9d/torch/csrc/jit/api/module.cpp#L502

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Segmentation fault when running torch.nn.AdaptiveMaxPool3d
Labels: triaged, module: edge cases

### 🐛 Describe the bug

If torch.nn.AdaptiveMaxPool3d is given very large list elements, it results in segmentation fault.

```
import torch
import numpy as np
arg_1_0 = 125091515651
arg_1_1 = 125091515651
arg_1_2 = 125091515651
arg_1 = [arg_1_0,arg_1_1,arg_1_2,]
arg_class = torch.nn.AdaptiveMaxPool3d(arg_1,)
arg_2_0_tensor = torch.rand([2, 3, 5, 6, 7], dtype=torch.float64)
arg_2_0 = arg_2_0_tensor.clone()
arg_2 = [arg_2_0,]
try:
  res = arg_class(*arg_2)
except Exception as e:
  print("Error:"+str(e))
```

The log message is:

```
Segmentation fault (core dumped)
```

### Versions

Collecting environment information...
PyTorch version: 1.8.0
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.6
Libc version: glibc-2.27

Python version: 3.8.16 (default, Dec  7 2022, 01:12:13)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.133+-x86_64-with-glibc2.27
Is CUDA available: False
CUDA runtime version: 11.2.152
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.8.0
[pip3] torchaudio==0.13.0+cu116
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.14.0
[pip3] torchvision==0.14.0+cu116
[conda] Could not collect
Overflow when running torch.nn.AdaptiveMaxPool3d on torch 1.12.0 and 1.13.1
Labels: triaged, module: edge cases

### 🐛 Describe the bug

When running torch.nn.AdaptiveMaxPool3d, it overflows with very large elements in input lists. 

```
import torch
import numpy as np
arg_1_0 = 125091515651
arg_1_1 = 125091515651
arg_1_2 = 125091515651
arg_1 = [arg_1_0,arg_1_1,arg_1_2,]
arg_class = torch.nn.AdaptiveMaxPool3d(arg_1,)
arg_2_0_tensor = torch.rand([2, 3, 5, 6, 7], dtype=torch.float64)
arg_2_0 = arg_2_0_tensor.clone()
arg_2 = [arg_2_0,]
try:
  res = arg_class(*arg_2)
except Exception as e:
  print("Error:"+str(e))
```

Log message:

```
Error:Storage size calculation overflowed with sizes=[2, 3, 125091515651, 125091515651, 125091515651]
```

### Versions

Collecting environment information...
PyTorch version: 1.13.0+cu116
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.6
Libc version: glibc-2.27

Python version: 3.8.16 (default, Dec  7 2022, 01:12:13)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.133+-x86_64-with-glibc2.27
Is CUDA available: False
CUDA runtime version: 11.2.152
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.12.0
[pip3] torchaudio==0.13.0+cu116
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.14.0
[pip3] torchvision==0.14.0+cu116
[conda] Could not collect
Segmentation fault when running torch.nn.AdaptiveMaxPool2d
Labels: triaged, module: edge cases

### 🐛 Describe the bug

If torch.nn.AdaptiveMaxPool2d is given very large list elements, it results in segmentation fault:

```
import torch
import numpy as np
arg_1_0 = 125091515651
arg_1_1 = 125091515651
arg_1 = [arg_1_0,arg_1_1,]
arg_class = torch.nn.AdaptiveMaxPool2d(arg_1,)
arg_2_0_tensor = torch.rand([1, 3, 5, 6], dtype=torch.float64)
arg_2_0 = arg_2_0_tensor.clone()
arg_2 = [arg_2_0,]
try:
  res = arg_class(*arg_2)
except Exception as e:
  print("Error:"+str(e))
```

The log message is:

```
Segmentation fault (core dumped)
```

Here is the link to [gist](https://colab.research.google.com/gist/nimashiri/973e5abe10001083c7ebce01171a11da/tensorflow-python-ops-gen_list_ops-tensor_list_from_tensor.ipynb)

### Versions

Collecting environment information...
PyTorch version: 1.8.0
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.3 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: version 3.24.3
Libc version: glibc-2.31

Python version: 3.8.10 (default, Nov 14 2022, 12:59:47)  [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.15.0-56-generic-x86_64-with-glibc2.29
Is CUDA available: True
CUDA runtime version: 11.0.194
CUDA_MODULE_LOADING set to: 
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1660 Ti
Nvidia driver version: 510.108.03
cuDNN version: Probably one of the following:
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.19.5
[pip3] pytorch-lightning==1.5.6
[pip3] pytorch-ranger==0.1.1
[pip3] torch==1.8.0
[pip3] torch-geometric==2.0.4
[pip3] torch-tb-profiler==0.4.0
[conda] Could not collect