gopikrsmscs/torch-issues huggingface dataset:
Overflow when running torch.nn.AdaptiveMaxPool2d
Labels: triaged, module: pooling, module: edge cases

### 🐛 Describe the bug

Overflow when running  torch.nn.AdaptiveMaxPool2d with very large list elements:

```
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:

```
Error:Storage size calculation overflowed with sizes=[1, 3, 125091515651, 125091515651]
```

### Versions

Collecting environment information...
PyTorch version: 1.12.0+cu102
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.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
[Inductor] The Way of Input Mutation Handing Conflicts with CPP Kernel Declaration
Labels: triaged, oncall: pt2, module: cpu inductor

Input mutation handling results in alias of input and output buffers while CPP kernel always assumes that these buffers do not overlap with `__restrict__` qualifier. They caused conflict and may result in potential correctness issues due to compiler optimization. Take the test case `test_input_mutation1` in test_torchinductor.py as an example:
```python
        def fn(a):
            b = a + 1
            a.copy_(b)
            c = a + 2
            return a * b / c
```
The function above produces the following kernel code, where `in_ptr0` and `out_ptr1` are aliases. Should we make them as an inplace buffer instead?
```c++
extern "C" void kernel(const float* __restrict__ in_ptr0,
                       float* __restrict__ out_ptr1,
                       float* __restrict__ out_ptr2)
{
    for(long i0=0; i0<4; i0+=1)
    {
        auto tmp0 = at::vec::Vectorized<float>::loadu(in_ptr0 + 16*i0);
        auto tmp1 = at::vec::Vectorized<float>(static_cast<float>(1));
        auto tmp2 = tmp0 + tmp1;
        auto tmp3 = tmp2 * tmp2;
        auto tmp4 = at::vec::Vectorized<float>(static_cast<float>(2));
        auto tmp5 = tmp2 + tmp4;
        auto tmp6 = tmp3 / tmp5;
        tmp2.store(out_ptr1 + 16*i0);
        tmp6.store(out_ptr2 + 16*i0);
    }
    #pragma omp simd simdlen(8)
    for(long i0=64; i0<64; i0+=1)
    {
        auto tmp0 = out_ptr1[i0];
        auto tmp1 = static_cast<float>(1);
        auto tmp2 = tmp0 + tmp1;
        auto tmp3 = tmp2 * tmp2;
        auto tmp4 = static_cast<float>(2);
        auto tmp5 = tmp2 + tmp4;
        auto tmp6 = tmp3 / tmp5;
        out_ptr1[i0] = tmp2;
        out_ptr2[i0] = tmp6;
    }
}
```

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
Adding label smoothing option to `nn.BCELoss`  and `nn.BCEWithLogitsLoss`?
Labels: module: nn, module: loss, triaged, actionable

### 🚀 The feature, motivation and pitch

Hello, I was looking at BCELoss and CrossEntropyLoss and found that while the latter has the option to add label_smoothing, the former does not. 

### Alternatives

Seeing as how the reasoning used for performing label smoothing (i.e. the logit values having to go to $\pm\infty$ to approach 1 or 0) should also apply to sigmoid functions (which are used with BCELoss), it stands to reason that label smoothing can and should be implemented with BCELoss? (i.e. for ex :  if the label value is 1, with label smoothing of 0.2, the value should be 0.8?)

### Additional context

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
Python 3.11.1 , even with nightly version of PyTorch: ERROR: No matching distribution found for torch
Labels: oncall: binaries, triaged

### 🚀 The feature, motivation and pitch

```
Defaulting to user installation because normal site-packages is not writeable
Looking in indexes: https://pypi.org/simple, https://pypi.ngc.nvidia.com, https://download.pytorch.org/whl/cu117
ERROR: Could not find a version that satisfies the requirement torch (from versions: none)
ERROR: No matching distribution found for torch
```
### Alternatives

_No response_

### Additional context

See https://stackoverflow.com/questions/74967443/error-no-matching-distribution-found-for-torch

cc @ezyang @seemethere @malfet
functorch.so is installed back into the source directory
Labels: module: build, triaged, module: functorch

### 🐛 Describe the bug

It installs this file:
```
/usr/ports/misc/py-pytorch/work/pytorch-v1.13.1/functorch/functorch.so
```
where ```/usr/ports/misc/py-pytorch/work/pytorch-v1.13.1``` is a source directory it was built from.

cmake args:
-DPSIMD_SOURCE_DIR=/usr/ports/misc/py-pytorch/work/pytorch-v1.13.1/third_party/psimd  -DFREEBSD_PYTHON_VER=3.9  -DPYTHON_EXECUTABLE:STRING=/usr/local/bin/python3.9 -DBUILD_PYTHON:BOOL=true -DCMAKE_C_COMPILER:STRING="cc"  -DCMAKE_CXX_COMPILER:STRING="c++"  -DCMAKE_C_FLAGS:STRING="-O2 -pipe  -fstack-protector-strong -fno-strict-aliasing "  -DCMAKE_C_FLAGS_DEBUG:STRING="-O2 -pipe  -fstack-protector-strong -fno-strict-aliasing "  -DCMAKE_C_FLAGS_RELEASE:STRING="-O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -DNDEBUG"  -DCMAKE_CXX_FLAGS:STRING="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing  "  -DCMAKE_CXX_FLAGS_DEBUG:STRING="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing  "  -DCMAKE_CXX_FLAGS_RELEASE:STRING="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing   -DNDEBUG"  -DCMAKE_EXE_LINKER_FLAGS:STRING=" -lexecinfo -fstack-protector-strong "  -DCMAKE_MODULE_LINKER_FLAGS:STRING=" -lexecinfo -fstack-protector-strong "  -DCMAKE_SHARED_LINKER_FLAGS:STRING=" -lexecinfo -fstack-protector-strong "  -DCMAKE_INSTALL_PREFIX:PATH="/usr/local"  -DCMAKE_BUILD_TYPE:STRING="Release"  -DTHREADS_HAVE_PTHREAD_ARG:BOOL=YES  -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=YES  -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON  -DFETCHCONTENT_FULLY_DISCONNECTED:BOOL=ON -DBUILD_CUSTOM_PROTOBUF:BOOL=OFF -DUSE_CUDA:BOOL=OFF -DUSE_ROCM:BOOL=OFF -DUSE_NNPACK:BOOL=OFF -DUSE_QNNPACK:BOOL=OFF -DUSE_PYTORCH_QNNPACK:BOOL=OFF -DUSE_FBGEMM:BOOL=OFF -GNinja -DPython_ADDITIONAL_VERSIONS=3.9 -DBOOST_PYTHON_SUFFIX:STRING=39


Version: 1.13.1
Python-3.9
FreeBSD 13.1


### Versions

```
$ python3.9 ./work/pytorch-v1.13.1/torch/utils/collect_env.py
Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: freebsd13
GCC version: Could not collect
Clang version: 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
CMake version: version 3.24.3
Libc version: N/A

Python version: 3.9.16 (main, Dec 18 2022, 01:15:32)  [Clang 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a (64-bit runtime)
Python platform: FreeBSD-13.1-STABLE-amd64-64bit-ELF
Is CUDA available: N/A
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 2060
Nvidia driver version: 510.60.02
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] mypy-protobuf==3.3.0
[pip3] numpy==1.23.4
[conda] Could not collect
```

cc @malfet @seemethere @zou3519 @Chillee @samdow @soumith
[functorch] make batch norm docs point to UX limitations
Labels: triaged, module: functorch

UX limitations docs haven't been pulled over yet but batch norm docs have. We should make the batch norm docs point to the UX limitations section on in-place mutations when it talks about why batch norm doesn't generally work

See https://github.com/pytorch/pytorch/pull/89213#discussion_r1058373807

cc @zou3519 @Chillee @soumith
Update map_nt to take into account size and strides
Labels: triaged, module: nestedtensor, bug

# Summary

Since map_nt doesn't check that the input is contiguous but only that the numels of the input match that of the buffer. This is in order to allow for the unary ops to be run on transposed inputs. We should also update the  map_nt to construct the output tensor with the same stride and offset information.

cc @cpuhrsch @jbschlosser @bhosmer @mikaylagawarecki
DISABLED test_tensor_requires_grad (test_jit.TestScript)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_tensor_requires_grad) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_tensor_requires_grad`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_rand (test_jit.TestScript)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_rand) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_rand`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_optional_tensor (test_jit.TestScript)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_optional_tensor) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_optional_tensor`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_prim_grad_undefined (test_jit.TestScript)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_prim_grad_undefined) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_prim_grad_undefined`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_requires_grad_loop (test_jit.TestScript)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_requires_grad_loop) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_requires_grad_loop`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_successful (jit.test_freezing.TestMKLDNNReinplacing)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_successful) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_successful`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_switch_inputs_to_inplace (jit.test_freezing.TestMKLDNNReinplacing)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_switch_inputs_to_inplace) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_switch_inputs_to_inplace`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_always_alive_values (jit.test_freezing.TestMKLDNNReinplacing)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_always_alive_values) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_always_alive_values`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_optional_list (test_jit.TestScript)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_optional_list) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_optional_list`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_tensor_as_tensor_shape_prop (test_jit.TestScript)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_tensor_as_tensor_shape_prop) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_tensor_as_tensor_shape_prop`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
DISABLED test_merge_liveness (jit.test_freezing.TestMKLDNNReinplacing)
Labels: oncall: jit, module: flaky-tests, skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_merge_liveness) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/10335682113).

Over the past 72 hours, it has flakily failed in 2 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_merge_liveness`


cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Clean up nt impl duplicates where one can
Labels: triaged, better-engineering, module: nestedtensor, release notes: nested tensor

# Summary
There is overlap between some of the NestedTensor implementations defined in NestedTensorMath.cpp and NestedTensorTransformerFunctions.cpp. As well since NestedTensorMath was the only cpp file for a while some of the implementations would be better suited to different files for organizational purposes. This issue is used to track the clean up of the code base.

cc @cpuhrsch @jbschlosser @bhosmer @mikaylagawarecki
torch.compile loud error on functorch transforms
Labels: triaged, oncall: pt2, module: functorch, module: dynamo

## Issue description

I would have expected these to fall back to eager mode, given that functorch transforms have try-catch blocks and context managers that dynamo should bail out of.

## Code example
```py
 def f(x):
     y = x * x * x * x * x * 1. * 1. * 1.
     return y

 def g(x):
     return torch.vmap(f)(x)

 cg = torch.compile(backend='aot_eager')(g)

 x = torch.randn(5)
 # Very loud error: dynamo/fake_tensor needs to peek into storage()
 # result = cg(x)
 expected = g(x)

 def g(x):
     return torch.func.grad(f)(x)

 cg = torch.compile(backend='aot_eager')(g)

 x = torch.randn([])
 expected = g(x)
 # Very loud error: dynamo needs to peek into storage()
 # result = cg(x)

 assert torch.allclose(result, expected)
```

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh @Chillee @samdow @mlazos @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire
torch.compile with aotautograd does not support double backwards
Labels: module: autograd, triaged, enhancement, oncall: pt2, module: aotdispatch

## Code example

The second-order gradients are completely bogus:
```py
def f(x):
    # Just to make sure there isn't a limit or something
    y = x * x * x * x * x * 1 * 1 * 1. * 1. * 1.
    print("graph_break")
    gx, = torch.autograd.grad(y, x, create_graph=True)
    ggx, = torch.autograd.grad(gx, x)
    return gx, ggx

x = torch.tensor(1., requires_grad=True)
of = torch.compile(backend='aot_eager')(f)

gx, ggx = f(x)
ogx, oggx = of(x)
assert torch.allclose(gx, ogx)
# BUG: second-order gradients are completely bogus. assertion failed
assert torch.allclose(ggx, oggx)
```

## Fix

Easy short-term fix is likely marking the autograd.Function backward pass as once_differentiable and adding a better error message

cc @ezyang @gchanan @albanD @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @soumith @msaroufim @wconstab @ngimel @bdhirsh
torch.compile incorrect when imperative autograd APIs are used
Labels: high priority, module: autograd, triaged, oncall: pt2, module: aotdispatch

## Issue description

torch.compile may be silently incorrect when Tensor.retain_grad or Tensor.register_hook are involved.

## Code example

Example with retain_grad:
```py
 # Test 1:
 # Tensor.retain_grad inside function
 # on intermediate, and on output
 # See if the grad can be used :P

 def f(x):
     y = x.clone()
     y.retain_grad()
     z = y.clone()
     z.retain_grad()
     return z, y

 of = torch.compile(backend='aot_eager')(f)

 x = torch.randn([], requires_grad=True)
 z, y = of(x)
 z.clone().backward()
 # inspect z.grad, y.grad
 # Bug: they do not exist. May lead to silent correctness problems
```

Example with register_hook:
```py
# If you register a hook on an intermediate, it won't work.
def f(x):
    y = x * x
    z = y * x * x * x * 1 * 1 * 1. * 1. * 1.
    print("graph_break")
    y.register_hook(lambda x: x if x is None else 3.14 * x)
    result, = torch.autograd.grad(z, x)
    return result

of = torch.compile(backend='aot_eager')(f)
x = torch.tensor(1., requires_grad=True)

expected = f(x)
result = of(x)
# assertion failed
assert torch.allclose(result, expected)
```

cc @ezyang @gchanan @albanD @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @soumith @msaroufim @wconstab @ngimel @bdhirsh
DISABLED test_fs_preserve_sharing (__main__.TestMultiprocessing)
Labels: module: multiprocessing, triaged, skipped, module: dynamo

Platforms: dynamo

This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/test_fs_preserve_sharing%2CTestMultiprocessing)).

It looks like the temp `/dev/shm/torch_*` files are not cleaned up properly when running with dynamo

cc @VitalyFedyunin @ejguan @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire
Degenerate ranges are allowed in NumPy, but not in PyTorch.
Labels: triaged, module: numpy

### 🐛 Describe the bug

```python
import torch as t
t.arange(5, 0)
```

Result:
```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: upper bound and larger bound inconsistent with step sign
```

I can understand why this behavior was implemented, but it seems wrong for a few reasons:

1. NumPy, whose API heavily inspires that of PyTorch, allows this:
```python
>>> import numpy as np
>>> np.arange(5, 0)
array([], dtype=int64)
```
2. Most programming languages (including Python), are perfectly happy letting you construct degenerate ranges.

### Versions

```
Collecting environment information...
/home/brennan/.local/lib/python3.10/site-packages/torch/cuda/__init__.py:146: UserWarning: 
NVIDIA GeForce RTX 3080 Laptop GPU with CUDA capability sm_86 is not compatible with the current PyTorch installation.
The current PyTorch install supports CUDA capabilities sm_37 sm_50 sm_60 sm_70.
If you want to use the NVIDIA GeForce RTX 3080 Laptop GPU GPU with PyTorch, please check the instructions at https://pytorch.org/get-started/locally/

  warnings.warn(incompatible_device_warn.format(device_name, capability, " ".join(arch_list), device_name))
PyTorch version: 1.12.1+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.10 (x86_64)
GCC version: (Ubuntu 12.2.0-3ubuntu1) 12.2.0
Clang version: 15.0.2-1
CMake version: version 3.24.2
Libc version: glibc-2.36

Python version: 3.10.7 (main, Nov 24 2022, 19:45:47) [GCC 12.2.0] (64-bit runtime)
Python platform: Linux-5.19.0-26-generic-x86_64-with-glibc2.36
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: 
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3080 Laptop GPU
Nvidia driver version: 515.86.01
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-boto3-ec2==1.23.0.post1
[pip3] mypy-boto3-elbv2==1.23.0.post1
[pip3] mypy-boto3-resourcegroupstaggingapi==1.23.0.post1
[pip3] mypy-boto3-route53==1.23.0.post1
[pip3] mypy-boto3-s3==1.23.0.post1
[pip3] mypy-boto3-sts==1.23.1
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.5
[pip3] torch==1.12.1
[conda] Could not collect
```

cc @mruberry @rgommers
Batch_first attribute in quantizable multiheadattention
Labels: oncall: transformer/mha

### 🐛 Describe the bug

I think that in the module torch.ao.nn.quantizable.modules.activation.MultiheadAttention in the method from_float passing the attribute batch_first is missing.
```python
@classmethod
def from_float(cls, other):
    assert type(other) == cls._FLOAT_MODULE
    assert hasattr(other, 'qconfig'), "The float module must have 'qconfig'"
    # Setting the dropout to 0.0!
    observed = cls(other.embed_dim, other.num_heads, other.dropout,
                   (other.in_proj_bias is not None),
                   (other.bias_k is not None),
                   other.add_zero_attn, other.kdim, other.vdim)
```
And because of it one can not set batch_first format when quantizing MultiheadAttention layer. 

### Versions

PyTorch version: 1.13.0+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Clang version: Could not collect
CMake version: version 3.25.0
Libc version: glibc-2.10

Python version: 3.7.9 (default, Aug 31 2020, 12:42:55)  [GCC 7.3.0] (64-bit runtime)
Python platform: Linux-5.4.0-84-generic-x86_64-with-debian-bullseye-sid
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: 
GPU 0: GeForce RTX 2080 Ti
GPU 1: GeForce RTX 2080 Ti

Nvidia driver version: 455.23.04
cuDNN version: Probably one of the following:
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn.so.8
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_adv_train.so.8
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8
/usr/local/cuda-11.4/targets/x86_64-linux/lib/libcudnn_ops_train.so.8
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] pytorch-wpe==0.0.1
[pip3] torch==1.13.0
[pip3] torch-complex==0.4.3
[pip3] torch-tb-profiler==0.4.0
[pip3] torchaudio==0.13.0
[pip3] torchvision==0.14.0
[conda] numpy                     1.21.6                   pypi_0    pypi
[conda] pytorch-wpe               0.0.1                    pypi_0    pypi
[conda] torch                     1.13.0                   pypi_0    pypi
[conda] torch-complex             0.4.3                    pypi_0    pypi
[conda] torch-tb-profiler         0.4.0                    pypi_0    pypi
[conda] torchaudio                0.13.0                   pypi_0    pypi
[conda] torchvision               0.14.0                   pypi_0    pypi


cc @jbschlosser @bhosmer @cpuhrsch @erichan1
[bazel] error: use of undeclared identifier 'cudaGraphDebugDotPrint'
Labels: module: build, module: cuda, triaged

### 🐛 Describe the bug

I’m trying to build with bazel from the tip of the master (`67c53d50e5b34a536cce2ad98b9ca5f65ff8a34d` at the time of writing) and I'm getting this error

```
external/pytorch/aten/src/ATen/cuda/CUDAGraph.cpp:259:27: error: use of undeclared identifier 'cudaGraphDebugDotPrint'
      C10_CUDA_CHECK_WARN(cudaGraphDebugDotPrint(graph_, debug_path.c_str(), 1<<10)); // most verbose output
```

I looked at the PR that introduced this code at https://github.com/pytorch/pytorch/pull/85519/files and I fail to understand where is cudaGraphDebugDotPrint defined…

Note that I'm building slightly patched version (with Cruise internal patches, primarily related to build).
I haven't tried to repro this on the unpatched OSS version, but CI didn't catch it...

### Versions

master `67c53d50e5b34a536cce2ad98b9ca5f65ff8a34d`

cc @malfet @seemethere @ngimel
Pytorch clang-tidy header-filter is still broken
Labels: module: build, triaged

### 🐛 Describe the bug

Header-Filter for Clang-Tidy is broken. Currently, almost no headers are analyzed by the clang-tidy analyzer. I tried to fix this in a recent PR by extending the header filter to C10, but ultimately ended up making the same mistake. The current regex is invalid because LLVM does not support lookahead/lookbehinds in it's regex engine.

### Versions

I tried to fix clang-tidy's header filter specified in .clang-tidy and it worked when I ran the regex through a python code snippit. However, I now have realized that even the original regex was actually broken this whole time because llvm does NOT support regex with lookahead or lookbehinds: https://stackoverflow.com/questions/71797349/is-it-possible-to-ignore-a-header-with-clang-tidy . This means that we are not running any clang-tidy static analysis on ANY of our header files currently which is allowing a lot of performance issues to permeate the code base, (especially in templates).

Not sure what the best way to reconstruct the current regex is without lookaheads. Any recommendations from folks? I can try just to positively include matching folders for all but the currently excluded folders, but that seems error prone as new folder will likely not be added as refactoring of the codebase continues.

cc @malfet @seemethere
PyObject preservation and resurrection for `StorageImpl`
Labels: module: internals, triaged, enhancement, better-engineering

It may be useful for `StorageImpl` to support PyObject preservation and resurrection.

TensorImpl has this behavior. When a reference count to the PyObject for a tensor goes to zero, but its associated TensorImpl is still being used, the ownership is flipped so that the TensorImpl hangs onto the PyObject, preventing it from getting deallocated. If the PyObject ever needs to be resurrected again, ownership is flipped again and the PyObject is given back to Python. The Python object will retain all of the properties it had before, since it was never deallocated. See #55686

cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh
getting issue 'typeindex' file not found in Littorch-Lite/install/include/ATen/core/custom_class.h
Labels: oncall: mobile

### 🐛 Describe the bug

in   Littorch-Lite/install/include/ATen/core/custom_class.h
#pragma once

#include <typeindex>
#include <memory>

### Versions

Hello Team,
I am using    pod 'LibTorch-Lite','1.13.0.1' in podfile  of iOS app with swift language. while building app getting error  ''typeindex' file not found' in file  Littorch-Lite/install/include/ATen/core/custom_class.h at line number 3.
Kindly Help.
Internal Assert failed
Labels: module: cuda, triaged, module: cuda graphs

### 🐛 Describe the bug

I am using an EncoderDecoder model from hugging face with Bert-base uncased as both encoder and decoder. I am getting this by running this code. 

from transformers import Seq2SeqTrainingArguments, Seq2SeqTrainer

training_args = Seq2SeqTrainingArguments(
    output_dir="./",
    learning_rate=5e-5,
    evaluation_strategy="steps",
    per_device_train_batch_size=4,
    per_device_eval_batch_size=8,
    predict_with_generate=True,
    overwrite_output_dir=True,
    save_total_limit=3,
    fp16=True, 
)

trainer = Seq2SeqTrainer(
    model=bert2bert,
    tokenizer=tokenizer,
    args=training_args,
    compute_metrics=compute_metrics,
    train_dataset=train,
    eval_dataset=test,
)

RuntimeError: false INTERNAL ASSERT FAILED at "../c10/cuda/CUDAGraphsC10Utils.h":73, please report a bug to PyTorch. Unknown CUDA graph CaptureStatus32508


### Versions

--2022-12-24 21:02:31--  https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.108.133, 185.199.109.133, 185.199.110.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17278 (17K) [text/plain]
Saving to: ‘collect_env.py’

collect_env.py      100%[===================>]  16.87K  --.-KB/s    in 0s      

2022-12-24 21:02:32 (77.8 MB/s) - ‘collect_env.py’ saved [17278/17278]

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

cc @ngimel @mcarilli @ezyang
[RFC] `quantile` should work for `float16`/`half` on the GPU
Labels: module: cuda, triaged, enhancement, module: half

### 🚀 The feature, motivation and pitch

The `torch.quantile`/`torch.Tensor.quantile` function should work with `float16` (half precision) inputs on the GPU. 

Currently, 
```python
import torch

a = torch.randn(10, 10, dtype=torch.float16, device="cuda")
b = torch.tensor(0.25, dtype=torch.float16, device="cuda")

a.quantile(b)
# or
torch.quantile(a, b)
```
fails with
```python
RuntimeError: quantile() input tensor must be either float or double dtype
```

Instead, it should just work.

Also the same goes for the scalar versions (for consistency with `float32` and `float64` versions)
```python
a.quantile(0.25)
# or
torch.quantile(a, 0.25)
```

### Alternatives

_No response_

### Additional context

I was asked to resubmit this as an RFC. See #91156.

cc @ngimel
PyTorch memory leak reference cycle in for loop, Mac M1 
Labels: triaged, module: arm, module: mps

### 🐛 Describe the bug


I am facing a memory leak when iteratively updating tensors in PyTorch on my Mac M1 GPU using the PyTorch mps interface. The following is a minimal reproducible example that replicates the behavior:

```python
import torch 

def leak_example(p1, ubar, device):
    
    t1 = torch.cat((torch.diff(ubar, dim=0), torch.zeros_like(ubar[:1,:,:,:], dtype = torch.float32)), dim = 0)
    u1 = p1 + 2 * (t1)
    
    B = torch.rand_like(u1, device = device)
    mask = u1 < B
    
    a1 = u1
    a1[~mask] = torch.rand_like(a1)[~mask]
    return a1

if torch.cuda.is_available(): # cuda gpus
    device = torch.device("cuda")
elif torch.backends.mps.is_available(): # mac gpus
    device = torch.device("mps")
torch.set_grad_enabled(False)
        
p1 = torch.rand(5, 5, 224, 224, device = device)
ubar = torch.rand(5, 5, 224, 224, device = device)
for i in range(10000):
    p1 = leak_example(p1, ubar, device)    
```

My Mac's GPU memory steadily grows when I execute this loop. I have tried running it on a CUDA GPU in Google Colab and the output of `print(torch.cuda.memory_allocated()/1024**2)` remains constant, though the GPU's Active memory, Non-releasable memory, and Allocated memory do appear to increase as the loop progresses (the output of `torch.cuda.memory_summary()`).

I have tried detaching and cloning the tensors and using weakrefs, to no avail. Interestingly, if I don't reassign the output of `leak_example` to `p1`, the behavior disappears, so it really seems related to the recursive assignment. Also, if I drop the `torch.diff()` assignment, the memory increase stalls out at some point, so it may be related to this function. Does anyone have any idea how I could resolve this?

### Versions

PyTorch version: 1.13.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.5.1 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.102)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.15 (main, Nov 24 2022, 08:28:41)  [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-12.5.1-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.13.0
[conda] numpy                     1.23.4           py39h1398885_0  
[conda] numpy-base                1.23.4           py39h90707a3_0  
[conda] torch                     1.13.0                   pypi_0    pypi

cc @malfet @kulinseth @albanD @DenisVieriu97 @razarmehr @abhudev
MPS backend does not accept int64 model weights or input data
Labels: triaged, module: mps

### 🐛 Describe the bug

I am trying to send my pretrained model to M2 GPU with the new MPS backend from PyTorch, but I am getting a TypeError that int64 tensors are not supported in the MPS backend.

Steps to reproduce the problem
- Setup Enformer pretrained model from EleutherAI via: https://github.com/lucidrains/enformer-pytorch 


- Send model to GPU and try to run inference:
```python
class EnformerInference:
    def __init__(self, data_path: str, model_path="EleutherAI/enformer-official-rough"):
         if torch.backends.mps.is_available():
             print("Using Apple Silicon GPU")
             device = torch.device("mps")
         else:
             print("Using CPU")
             device = torch.device("cpu")

        self.device = device
        self.model = Enformer.from_pretrained(model_path).to(device)
        self.data = EnformerDataLoader(pd.read_csv(data_path, sep="\t"))

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        return self.model(x.to(self.device))
```
- Error: `TypeError: Operation 'abs_out_mps()' does not support input type 'int64' in MPS backend.`

I have checked all my input tensors and they are of type float32. The weights of the Enformer model on the other hand are not all of type float32 as some are int64. I have tried to recast the weights of my model to float32 using the following code:
```python
weights = self.model.state_dict()
for name, param in weights.items():
  weights[name] = param.to(torch.float32)
self.model = self.model.load_state_dict(weights)
```

However, this did not preserve the original PyTorch pretrained model object.

### Versions

PyTorch version: 1.13.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.1 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.202)
CMake version: Could not collect
Libc version: N/A

Python version: 3.10.8 | packaged by conda-forge | (main, Nov 22 2022, 08:25:29) [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-13.1-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.24.0
[pip3] torch==1.13.1
[pip3] torchaudio==0.13.1
[pip3] torchvision==0.14.1
[conda] numpy                     1.24.0          py310h5d7c261_0    conda-forge
[conda] pytorch                   1.13.1                 py3.10_0    pytorch
[conda] torchaudio                0.13.1                py310_cpu    pytorch
[conda] torchvision               0.14.1                py310_cpu    pytorch


cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
Offer `get_buffer` and `get_submodule` in `ScriptModule`?
Labels: oncall: jit

### 🚀 The feature, motivation and pitch

This is something in-between a feature request / documentation issue / bug report.

The documentation of [`ScriptModule`](https://pytorch.org/docs/stable/generated/torch.jit.ScriptModule.html#torch.jit.ScriptModule) documents that the class offers [`get_buffer`](https://pytorch.org/docs/stable/generated/torch.jit.ScriptModule.html#torch.jit.ScriptModule.get_buffer) and [`get_submodule`](https://pytorch.org/docs/stable/generated/torch.jit.ScriptModule.html#torch.jit.ScriptModule.get_submodule). This doesn't seem to be the case though, because trying to access them errors with

```
RuntimeError: get_buffer is not supported on ScriptModules
```

because they are not in the allow list here:

https://github.com/pytorch/pytorch/blob/71d50f4f8955cde773e30b207bfeb98616206823/torch/jit/_script.py#L943

Since `ScriptModules` apparently offers access the buffers and modules, it would feel more consistent if these methods were allowed, right? Furthermore they could offer extra safety when trying to access non-existing buffers/modules. In particular I was running into a bug because setting a buffer like the following is possible without an error:

```py
# Attempting to set a "known" buffer, but due to a typo it didn't have an effect.
# Unfortunately this doesn't seem to error, which hides the fact that there is a typo.
my_script_module.buffer_with_typo = torch.tensor(True)
```

I was hoping that I can use `get_buffer` instead, which (hopefully) would perform a check if the buffer actually exists:

```py
# Would hope that this gives a clear error if the accessed buffer doesn't exist.
my_script_module.get_buffer("buffer_with_typo").copy_(torch.tensor(True))
```

Since `get_buffer` isn't supported at all, this isn't possible though.

For now I'm resorting to `hasattr` checks to make this a bit more robust.

### Alternatives

Adapt the documentation to avoid suggesting the functions are usable.

### Additional context

_No response_

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
nop_partitioner for AOTAutograd
Labels: triaged, oncall: pt2, module: aotdispatch

### 🚀 The feature, motivation and pitch

Hello everyone, I've got an idea I'd like to share with you. It is about graph partitioners in AOTAutograd.

Currently, there are two partitioners defined (default_partition and min_cut_rematerialization_partition) which always result in two separate graphs, one for FWD and second for BWD. I would like to have an option to get whole joint graph containing both FWD and BWD to get most of optimization opportunities for my torch.compile backend.

I tried to implement such "nop_partitioner" myself that would just pass the joint graph back, as well as tried changing default_partition to gather more outputs into single graph, but it always resulted in some kind of crash. I assume that in current AOTAutograd code there might be hidden assumptions on this mechanism that do not allow this kind of operation (or my programming skills just suck, that's also possible).

Is it possible for you to create such "nop_partitioner" as part of PT2.0 release so it could be used by everyone?

Thanks,
--mb

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
Internal error during ONNX export, diagnostic unusable 
Labels: module: onnx, triaged

### 🐛 Describe the bug

 I encounter this internal error during export of relatively simple network using LSTM. 
 Same network can be jit.traced and executed just fine (well, after a Pytorch path I have submitted in issue #91351).
 I tried to create a simple repro case - but then it exports successfully. Still working on repro.
 
 But this issue is more general, I have encountered it in many cases  - how do I debug this ? 
 The message is rather cryptic, and the unique ID printed out (3555) seem to be internal to C lib - there is nothing in the ONNX graph printed on exception, that would help me to connect that ID with the graph. 
 
```
  File "/git/NeMo/nemo/core/classes/exportable.py", line 71, in export
    out, descr, out_example = model._export(
  File "/git/NeMo/nemo/core/classes/exportable.py", line 178, in _export
    torch.onnx.export(
  File "/usr/local/lib/python3.8/dist-packages/torch/onnx/utils.py", line 504, in export
    _export(
  File "/usr/local/lib/python3.8/dist-packages/torch/onnx/utils.py", line 1529, in _export
    graph, params_dict, torch_out = _model_to_graph(
  File "/usr/local/lib/python3.8/dist-packages/torch/onnx/utils.py", line 1115, in _model_to_graph
    graph = _optimize_graph(
  File "/usr/local/lib/python3.8/dist-packages/torch/onnx/utils.py", line 675, in _optimize_graph
    _C._jit_pass_lint(graph)
RuntimeError: 0 INTERNAL ASSERT FAILED at "/opt/pytorch/pytorch/torch/csrc/jit/ir/ir.cpp":590, please report a bug to PyTorch. 3555 not in scope
```

### Versions

Collecting environment information...
PyTorch version: 1.14.0a0+410ce96
Is debug build: False
CUDA used to build PyTorch: 11.8
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.24.1  
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-46-generic-x86_64-with-glibc2.29
Is CUDA available: True
CUDA runtime version: 11.8.89
GPU models and configuration: GPU 0: NVIDIA RTX A5000
Nvidia driver version: 515.65.01
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] k2==1.23.2.dev20221221+cuda11.8.torch1.14.0a0
[pip3] numpy==1.22.2
[pip3] pytorch-lightning==1.8.6
[pip3] pytorch-quantization==2.1.2
[pip3] torch==1.14.0a0+410ce96
[pip3] torch-tensorrt==1.3.0a0
[pip3] torchaudio==0.14.0
[pip3] torchmetrics==0.11.0
[pip3] torchvision==0.15.0a0
[conda] Could not collect
Remove redundant logics
Labels: triaged, oncall: pt2

In class SymInt, member data_(int64_t) can be casted to SymNodeImpl* by bit operation as follow:
https://github.com/pytorch/pytorch/blob/f471770fd40cae2065a8d066932ddf59e12a758d/c10/core/SymInt.h#L91-L99
It seems that `~MASK` always make 61st bit of `unextended_bits` as 0, which may leads to `(unextended_bits ^ sign_bit_mask) - sign_bit_mask` equal `unextended_bits` itself, not signed-extension(0b111........).
I’m confused that whether is there may be special circumstances to make signed-extension really happen, or just comment out L94-L96 is fine.

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
Pytorch 1.13 conda package with cuda requires too many unneccessary packages
Labels: oncall: binaries, module: cuda, triaged

With the switch from cudatoolkit to pytoch-cuda came a lot of very large "dependencies" that aren't actually dependencies and need to be eliminated.
[Related discusson](https://discuss.pytorch.org/t/large-cuda-dependencies-in-pytorch-1-13-conda-installation/165068).

cc @ezyang @seemethere @malfet @ngimel