gopikrsmscs/torch-issues huggingface dataset:
Installation on Jetson target board
Labels: triaged, module: jetson

I'm installing the pytorch on Jetson target board(Nx, AGX, nano...).
Official Pytorch for jetson wheel is only for python3.6, so I use the installation through the source.
However, during the installation, the error occured. 
My environment is : 
- board : Jetson Xavier AGX
- JetPack : 4.4
- Cuda: 10.2
- gcc, g++ : 7
- Cmake : 3.18.2
- 
![image](https://user-images.githubusercontent.com/17849068/169723455-1885b9b6-2f9c-48e4-9b64-09a7f31a9574.png)
![image](https://user-images.githubusercontent.com/17849068/169723466-75ced077-1024-405d-8567-be2b78939dca.png)
How can i solve it..? plz help....

Also , How can i download the lower version of pytorch(ex, 1.8.0) by using this source?

cc @ptrblck @puririshi98
Adam is 30% slower than SGD on Apple Metal.
Labels: module: performance, module: optimizer, triaged, module: mps

### 🐛 Describe the bug

I am benchmarking the Apple silicon on PyTorch and Adam is 30% slower than SGD.
<img width="1126" alt="image" src="https://user-images.githubusercontent.com/18441985/169709366-b415c24d-7a37-4cce-94ec-6c68e0a7d1dd.png">
You can check my experiments on this wandb workspace: 
https://wandb.ai/capecape/M1_TF_vs_PT?workspace=user-capecape

I am on latest Pytorch 22/05 nightly.

### Versions

Collecting environment information...
PyTorch version: 1.13.0.dev20220522
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.4 (arm64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.5)
CMake version: version 3.23.1
Libc version: N/A

Python version: 3.10.4 | packaged by conda-forge | (main, Mar 24 2022, 17:42:03) [Clang 12.0.1 ] (64-bit runtime)
Python platform: macOS-12.4-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.13.0.dev20220522
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] numpy                     1.22.3                   pypi_0    pypi
[conda] torch                     1.13.0.dev20220522          pypi_0    pypi
[conda] torchaudio                0.11.0                   pypi_0    pypi
[conda] torchvision               0.12.0                   pypi_0    pypi

cc @VitalyFedyunin @ngimel @vincentqb @jbschlosser @albanD
toleranceOverride should override atol and rtol even when explicitly specified in a test
Labels: module: tests, triaged, module: primTorch

This would allow a test's default atol/rtol to be set tighter but still allow operators to set the atol/rtol manually.

In primTorch this would let us set tighter atol and rtol for the reference consistency tests.

cc @mruberry @ezyang @ngimel
[FSDP] .modules() return original modules instead of FSDP prefixed modules
Labels: oncall: distributed, triaged, module: fsdp

### 🚀 The feature, motivation and pitch

FSDP destructively recreated a module and changed the module path, but users still expect to get the original module path in their application, override the .module() API to return the original module with a clean path. Similar to https://github.com/pytorch/pytorch/pull/74333, which overrides named_parameters() API to return named parameters with the clean paths. 

### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
Error occurred , when compile source code setting  BUILD_CAFFE2=ON
Labels: module: build, caffe2, triaged

### 🐛 Describe the bug

compile source code failed
# compile command:
TORCH_CUDA_ARCH_LIST="7.5" ONNX_NAMESPACE="torch_tmp" USE_NUMPY=0 USE_DISTRIBUTED=OFF USE_NCCL=OFF _GLIBCXX_USE_CXX11_ABI=0 REL_WITH_DEB_INFO=1 BUILD_CAFFE2=ON python setup.py install

## error print
<img width="1529" alt="image" src="https://user-images.githubusercontent.com/13358476/169635520-26b97a21-23e3-40f7-80bc-967f85d3049a.png">
<img width="1530" alt="image" src="https://user-images.githubusercontent.com/13358476/169635531-74175742-2b89-4245-be63-c43ebebc9ade.png">




### Versions


## envs:
---------------------- -------------------
astunparse             1.6.3
brotlipy               0.7.0
certifi                2021.10.8
cffi                   1.15.0
charset-normalizer     2.0.4
conda                  4.12.0
conda-package-handling 1.8.1
cryptography           37.0.1
future                 0.18.2
idna                   3.3
mkl-fft                1.3.1
mkl-random             1.2.2
mkl-service            2.4.0
numpy                  1.21.5
pip                    21.2.4
pycosat                0.6.3
pycparser              2.21
pyOpenSSL              22.0.0
PySocks                1.7.1
PyYAML                 6.0
requests               2.27.1
ruamel-yaml-conda      0.15.100
setuptools             61.2.0
six                    1.16.0
torch                  1.11.0a0+gitbc2c6ed
tqdm                   4.64.0
typing_extensions      4.1.1
urllib3                1.26.9
wheel                  0.37.1


cc @malfet @seemethere
Three memory copies of every dataloader cpu tensor
Labels: module: multiprocessing, module: dataloader, module: cuda, triaged, enhancement

### 🐛 Describe the bug

(from slack discussion with @albanD)

Is it possible to both share_memory and pin_memory for a tensor, for dataloading across shared memory with zero copies?
```
>>> x.share_memory_().pin_memory().is_shared()
False
>>> x.pin_memory().share_memory_().is_pinned()
False
```

It seems like the answer is no, since cudaHostAlloc doesn't seem to be compatible with shared memory, which is a shame because there's implicitly three full copies of every tensor generated by a dataset:
- dataset generates an example
- dataloader collates it
- dataloader copies it into shared memory to share with main process
- memory pinning thread copies into pinned memory before transfer to device

How might we reduce these extra copies? The H100 generation is going to start being impossible to feed.

(sort of related to https://pytorch.slack.com/archives/C3PDTEV8E/p1652536474661579 and https://pytorch.slack.com/archives/C3PDTEV8E/p1652844740547679)

### Versions

Not relevant, but I'm on PyTorch 1.11.0 and on CUDA 11.4, with 8x V100s or A100s.

cc @VitalyFedyunin @SsnL @ejguan @NivekT @ngimel
forward-mode support for "logically composite" operators
Labels: triaged, module: derivatives, module: forward ad

Today, in PyTorch, when we add forward-mode AD support for an operator, there are times when the forward-mode AD formula recomputes intermediate values used in the operator implementation. There is currently no way to share intermediate values between the operator implementation and forward-mode AD formula, especially if an operator implementation is some fused kernel.

Recomputation is sometimes not a problem; @Chillee's work on recomputation in AOTAutograd shows that when paired with a fuser, recomputation can be faster than sharing intermediate values due to avoiding relatively expensive memory transfers. However, PyTorch's many forward-mode AD formulas are not fused kernels (yet, at least :)).

This issue is an ask to investigate if we should reconsider how we are writing forward-mode AD formulas to avoid recomputation.

## Pitch

Let's consider a hypothetical operator. Assume that there is some fused CPU and CUDA kernel for it.
```
def mulmul_reference(a, b, c):
  mul1 = a * b
  mul2 = mul1 * c
  return mul2

def mulmul(a, b, c):
  return some_fast_kernel(a, b, c)
```
To add a forward-mode AD formula for it, today we would write it like the following:
```
def mulmul_jvp(a, a_t, b, b_t, c, c_t):
  mul1 = a * b
  mul1_t = a_t * b + a * b_t
  mul2_t = mul1 * c_t + mul1_t * c
  return mul2_t
```
Note that at some point, `mulmul` and `mulmul_jvp` both compute mul1.

### Proposal

Instead of writing `mulmul_jvp` we would implement `mulmul` like the following:
```
def mulmul(a, b, c):
  if any_is_dual_tensor(a, b, c):
    return mulmul_reference(a, b, c)
  return some_fast_kernel(a, b, c)
```
This gives us forward-mode AD support for mulmul AND it has the nice property that `mul1` does not get computed twice.

CC'ing folks who have been working on forward-mode AD-related things
cc @soulitzer @albanD @Lezcano @samdow
Inference Tensors should not be allowed to hold `grad_fn`
Labels: triaged, inference mode

### 🐛 Describe the bug

Here's a sneaky script to only override the backward implementation for a PyTorch op. This should not be used but posting to share what seems like a bug in Inference Tensor implementation (as per the title and comments in the code below).
```py
import torch

op = torch.ops.aten.sin.default

class MyFunc(torch.autograd.Function):
    @staticmethod
    def forward(ctx, input):
        ctx.save_for_backward(input)
        with torch.inference_mode():
            out = op(input)
        # returns an inference tensor with `grad_fn`. 
        # out.detach() also returns an inference tensor with a `grad_fn`
        return out
        # returns a non inference tensor with a `grad_fn` set
        return out.clone()

    @staticmethod
    def backward(ctx, grad_output):
        input, = ctx.saved_tensors
        return grad_output + input

mylib = torch.library.Library("aten", "IMPL")

mylib.impl("sin", MyFunc.apply, "AutogradCPU")

a = torch.zeros(10, requires_grad=True)
out = torch.sin(a)
print(out, out.sum(), torch.is_inference_mode_enabled(), torch.is_grad_enabled())
# errors out when we return an inference tensor since out.sum() magically returns a tensor with no `grad_fn`.
out.sum().backward()
print(out, a.grad)
```

### Versions

master
`logaddexp2` fails to backward
Labels: module: autograd, triaged, module: edge cases

### 🐛 Describe the bug

`logaddexp2` fails to backward

```python
import torch

input = torch.randint(0, 2, [1], dtype=torch.bool)
other = torch.rand([3], dtype=torch.float32, requires_grad=True)

res = torch.logaddexp2(input, other)

res.sum().backward()
# Subtraction, the `-` operator, with a bool tensor is not supported. If you are trying to invert a mask, use the `~` or `logical_not()` operator instead.
```

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Operating on boolean torch tensor and numpy array casts to `unit8`
Labels: triaged, module: numpy, module: type promotion, module: boolean tensor

### 🐛 Describe the bug

Sometimes one accidentally mixes `torch` and `numpy` arrays in the code. When this happens, `numpy` generally raises `TypeError`, while `torch` usually handles these situations gracefully. However, for boolean operations `torch` recasts to `uint8`, which leads to unexpected error messages down the road

```python
import numpy as np
import torch

x = torch.tensor(True) | np.array(True)
print(x)
```
outputs `tensor(1, dtype=torch.uint8)` with `dtype` `unit8`. Expected output would be `tensor(True)` with boolean dtype.



### Versions

PyTorch version: 1.11.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.31

Python version: 3.8.12 (default, Oct 12 2021, 13:49:34)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.13.0-41-generic-x86_64-with-glibc2.17
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy==0.941
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[conda] numpy                     1.22.3                   pypi_0    pypi
[conda] torch                     1.11.0                   pypi_0    pypi


cc @mruberry @rgommers @nairbv
Exporting the operator isinstance to ONNX opset version 13 is not supported
Labels: module: onnx, triaged, onnx-needs-info

### 🚀 The feature, motivation and pitch

Is it possible to add support for the operator `isinstance` in the ONNX opset please?
I cannot see any workaround to deal with my problem.
Thanks

### Alternatives

_No response_

### Additional context

_No response_
NaN tensor values problem for GTX16xx users  (no problem on other devices)
Labels: module: cudnn, triaged

### 🐛 Describe the bug

I use [yolov5 ](https://github.com/ultralytics/yolov5)to test with the demo dataset (coco128) and found that box and obj are nan. Also, there are no detections appear on validation images. This only happens on GTX1660ti devices (GPU mode), when I use CPU or use Google colab(Tesla K80) / RTX2070 for training, everything works fine.
![image](https://user-images.githubusercontent.com/17290550/169525214-44426c6b-11a0-4131-83ae-5b2869c19ba5.png)

The command used for training is
`python train.py`

There are issues here also discussing the same problem. 

- https://github.com/pytorch/pytorch/issues/58123
- https://github.com/openai/glide-text2im/issues/31
- https://discuss.pytorch.org/t/half-precision-convolution-cause-nan-in-forward-pass/117358/3
- https://github.com/pytorch/pytorch/issues/69449
- https://github.com/ultralytics/yolov5/issues/5815

However, I have tried pytorch with cuda version 11.5 (whose cudnn version is 8.3.0>8.2.2) and I also tried **downloading cuDNN from nvidia and copy/paste the dll files into the relevant folder in torch/lib** , the problem still can not be solved.

Another workaround is to downgrade to pytorch with cuda version 10.2(tested and it works), but this is currently not feasible as CUDA-10.2 PyTorch builds are no longer available for Windows.


Environment

- Windows 10 10.0.19044.1706
- YOLOv5-6.1 (version 6.1)
- Nvidia GTX 1660 TI, 6 GB
- Python3.9
- cudatoolkit-11.3.1
- pytorch-1.11.0-py3.9_cuda11.3_cudnn8_0
- (also tried pytorch-1.11.0-py3.9_cuda11.5_cudnn8_0)
- (with dependencies installed correctly)


cc @csarofeen @ptrblck @xwang233
`topk` returns different results with the same input twice in cuda
Labels: module: cuda, triaged, module: python frontend

### 🐛 Describe the bug

`topk` has different results for input with and without grad in cuda

```python
import torch

input_tensor = torch.tensor(0.4105, dtype=torch.float64)

k = 0
dim = 0
largest = True
sorted = True

input = input_tensor.clone().detach().to('cuda')
res1 = torch.topk(input, k, dim=dim, largest=largest, sorted=sorted, )

input = input_tensor.clone().detach().to('cuda')
res2 = torch.topk(input, k, dim=dim, largest=largest, sorted=sorted, )

input = input_tensor.clone().detach().to('cuda')
res3 = torch.topk(input, k, dim=dim, largest=largest, sorted=sorted, )

print(res1)
print(res2)
print(res3)
# torch.return_types.topk(
# values=tensor(0., device='cuda:0', dtype=torch.float64),
# indices=tensor(0, device='cuda:0'))

# torch.return_types.topk(
# values=tensor(0.4105, device='cuda:0', dtype=torch.float64),
# indices=tensor(0, device='cuda:0'))

# torch.return_types.topk(
# values=tensor(0.4105, device='cuda:0', dtype=torch.float64),
# indices=tensor(0, device='cuda:0'))
```

### Versions

pytorch: 1.11.0
cudakit: 11.3
GPU 0: NVIDIA GeForce RTX 3080 Ti


cc @ngimel
Heap corruption in slow_conv_transpose3d
Labels: module: convolution, triaged, module: edge cases

### 🐛 Describe the bug

Heap corruption in `slow_conv_transpose3d`.

### Example to reproduce

```python
import torch

tensor_0 = torch.empty((3, 3, 3, 3, 3,), dtype=torch.float32)
tensor_1 = torch.empty((3, 3, 3, 3, 3,), dtype=torch.float32)
intarrayref_2 = [2, 2, 2]
tensor_3 = torch.full((3,), 0.5, dtype=torch.float64, requires_grad=False)
intarrayref_4 = [1, 1, 1]
intarrayref_5 = [1, 1, 1]
intarrayref_6 = [-1250999896764, -1250999896764, -1250999896764]
intarrayref_7 = [1250999896764, 1250999896764, 1250999896764]
torch._C._nn.slow_conv_transpose3d(tensor_0, tensor_1, intarrayref_2, tensor_3, intarrayref_4, intarrayref_5, intarrayref_6, intarrayref_7)
```

### Result
```malloc_consolidate(): invalid chunk size```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
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: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[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.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Floating point exception in slow_conv3d
Labels: module: convolution, triaged, module: edge cases

### 🐛 Describe the bug

Floating point exception in `slow_conv3d`.

### Example to reproduce

```python
import torch

tensor_0 = torch.full((0, 0, 9, 15, 0, 0, 0, 0, 0, 8,), 1, dtype=torch.float64, requires_grad=False)
tensor_1 = torch.full((0, 0, 9, 15, 0, 0, 0, 0, 0, 8, 0, 11, 10, 3, 0,), 0.5, dtype=torch.float64, requires_grad=False)
intarrayref_2 = [-8608480567731124087, -8608480567731124087, -8608480567731124087]
tensor_3 = torch.full((), 1, dtype=torch.int64, requires_grad=False)
intarrayref_4 = [-8608480567731124087, -8608480567731124087, -8608480567731124087]
intarrayref_5 = [-8608480567731124087, -8608480567731124087, -8608480567731124087]
torch._C._nn.slow_conv3d(tensor_0, tensor_1, intarrayref_2, tensor_3, intarrayref_4, intarrayref_5)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
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: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[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.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Floating point exception in native_channel_shuffle
Labels: triaged, release notes: python_frontend

### 🐛 Describe the bug

Floating point exception in `native_channel_shuffle`.

### Example to reproduce

```python
import torch

self = torch.full((0, 0, 9, 15, 0, 0, 0, 0, 0, 8,), 1, dtype=torch.int64, requires_grad=False)
groups = 0
torch.native_channel_shuffle(self, groups)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
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: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[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.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Floating point exception in channel_shuffle
Labels: triaged, release notes: python_frontend

### 🐛 Describe the bug

Floating point exception in `channel_shuffle`.

### Example to reproduce

```python
import torch

self = torch.empty((0, 3, 8, 0, 6,), dtype=torch.float64)
groups = 1
torch.channel_shuffle(self, groups)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
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: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[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.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Segmentation fault in _remove_batch_dim
Labels: needs reproduction, triaged, module: vmap

### 🐛 Describe the bug

Segmentation fault in `_remove_batch_dim`.

### Example to reproduce

```python
import torch

self = torch.full((5, 5, 5, 5, 5,), 1, dtype=torch.float64, requires_grad=False)
level = 0
batch_size = 0
out_dim = 1250999896764
torch._remove_batch_dim(self, level, batch_size, out_dim)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
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: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[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.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch

cc @zou3519
Make the appropriate backend `DimensionNode` visible to LTC core
Labels: triaged, lazy

### 🚀 The feature, motivation and pitch

With the current implementation of `DimensionNode` in LTC, each backend has its own implementation ([PyTorch/XLA](https://github.com/pytorch/xla/pull/3558), [TorchScript](https://github.com/pytorch/pytorch/blob/master/torch/csrc/lazy/ts_backend/dynamic_ir.h#L46-L56)). 

At the same time, shape inference builds off of LTC core classes leading to this [PR](https://github.com/pytorch/pytorch/pull/77830) failing to build shape inference implementation for `expand.SymInt`. Please make the appropriate backend `DimensionNode` visible to LTC core.

**Solution** alternatives based on offline chat with @Krovatkin.
* IR core to access the correct backend implementation
* Use multiple inheritance

CC @wconstab @JackCaoG

### Alternatives

_No response_

### Additional context

_No response_
ONNX export of CumSum produces different data type
Labels: module: onnx, triaged, onnx-triaged

### 🐛 Describe the bug

When running a model with ```torch.cumsum(..., dtype=None)``` where dtype is set to None, an integer data type gets promoted to ```torch.int64```. However, if the same model gets exported to ONNX, the dtype does not get promoted. See following example:

```python
import torch
import onnx

class Model(torch.nn.Module):
    def forward(self, x):
        return x.cumsum(0, dtype=None), x.cumsum(0, dtype=torch.int32), x.cumsum(0, dtype=torch.float)

input = torch.rand(1, 2, 3).to(torch.int32)
model = Model()
output = model(input)

torch.onnx.export(model, input, 'error.onnx', opset_version=11)

omodel = onnx.load('error.onnx')
lookup = {
    onnx.TensorProto.BOOL:      'onnx.TensorProto.BOOL',
    onnx.TensorProto.DOUBLE:    'onnx.TensorProto.DOUBLE',
    onnx.TensorProto.FLOAT16:   'onnx.TensorProto.FLOAT16',
    onnx.TensorProto.FLOAT:     'onnx.TensorProto.FLOAT',
    onnx.TensorProto.INT8:      'onnx.TensorProto.INT8',
    onnx.TensorProto.INT16:     'onnx.TensorProto.INT16',
    onnx.TensorProto.INT32:     'onnx.TensorProto.INT32',
    onnx.TensorProto.INT64:     'onnx.TensorProto.INT64',
    onnx.TensorProto.UINT8:     'onnx.TensorProto.UINT8',
    onnx.TensorProto.UINT16:    'onnx.TensorProto.UINT16',
    onnx.TensorProto.UINT32:    'onnx.TensorProto.UINT32',
    onnx.TensorProto.UINT64:    'onnx.TensorProto.UINT64'
}

print('PyTorch Output DTypes: {}'.format(tuple(o.dtype for o in output)))
print('ONNX Output DTypes: {}'.format(
    tuple(lookup.get(o.type.tensor_type.elem_type) for o in omodel.graph.output))
)
```

Output is:
```
PyTorch Output DTypes: (torch.int64, torch.int32, torch.float32)
ONNX Output DTypes: ('onnx.TensorProto.INT32', 'onnx.TensorProto.INT32', 'onnx.TensorProto.FLOAT')
```

As you can see, in the ```dtype=None``` case, PyTorch uses INT64 while ONNX uses INT32.


### Versions

Collecting environment information...
PyTorch version: 1.11.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: CentOS Linux 7 (Core) (x86_64)
GCC version: (GCC) 10.3.0
Clang version: Could not collect
CMake version: version 3.23.1
Libc version: glibc-2.17

Python version: 3.7.12 (default, Feb  6 2022, 20:29:18)  [GCC 10.2.1 20210130 (Red Hat 10.2.1-11)] (64-bit runtime)
Python platform: Linux-3.10.0-1160.59.1.el7.x86_64-x86_64-with-centos-7.9.2009-Core
Is CUDA available: False
CUDA runtime version: 11.3.109
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.21.6
[pip3] torch==1.11.0
[pip3] torchvision==0.12.0
[conda] Could not collect
Legacy model format is not supported on mobile
Labels: oncall: mobile

### 🐛 Describe the bug

`
import torch

m = torch.jit.load('model.pt')
`
failed.  Notes: 
RuntimeError: Legacy model format is not supported on mobile.

## enviroment :
- torch version: 1.11.0

A model is traced by torch_1.9. when I load the model with torch_1.9, it  worked. if I load the model with torch_1.11, it failed.

![image](https://user-images.githubusercontent.com/13358476/169251678-40f21b0c-7a75-45c8-8e0a-7cf2debe169c.png)

what does the error mean? How to solve this problem? Thanks


### Versions

model traced by torch 1.9.0
expect to load the model  with torch_1.11
BUG: reference count leak when using `THPLayout_New` and `THPMemoryFormat_New` (static analyzer reports)
Labels: module: memory usage, triaged, module: python frontend

Hint 1: In function `THPLayout_New` and `THPMemoryFormat_New`, the `tp_alloc` method is used to allocate the memory for the PyObject to be returned. If the default allocator function is inherited, the function call will return a new reference.

Hint 2: Function `PyModule_AddObject` will steal a reference to the third argument only when the return value is zero.

---

* In function `initializeLayouts`, the trigger path provided by our analyzer is as follows. (Internal Report ID: e2a925)

1. A new reference is returned from `THPLayout_New` and assigned to `strided_layout`. (refcnt = 1)
https://github.com/pytorch/pytorch/blob/d1bb420fb1087d680b7ad526536e14acbc2f18bf/torch/csrc/utils/tensor_layouts.cpp#L25

2. Increase the refcnt. (refcnt = 2)
https://github.com/pytorch/pytorch/blob/d1bb420fb1087d680b7ad526536e14acbc2f18bf/torch/csrc/utils/tensor_layouts.cpp#L26

3. An exception is thrown without decreasing the refcnt.
https://github.com/pytorch/pytorch/blob/d1bb420fb1087d680b7ad526536e14acbc2f18bf/torch/csrc/utils/tensor_layouts.cpp#L28

---

* In lambda expression `add_memory_format` in function `initializeMemoryFormats`, the trigger path provided by our analyzer is as follows. (Internal Report ID: 09d8df)

1. A new reference is returned from `THPMemoryFormat_New` and assigned to `memory_format`. (refcnt = 1)
https://github.com/pytorch/pytorch/blob/d1bb420fb1087d680b7ad526536e14acbc2f18bf/torch/csrc/utils/tensor_memoryformats.cpp#L32

2. Increase the refcnt. (refcnt = 2)
https://github.com/pytorch/pytorch/blob/d1bb420fb1087d680b7ad526536e14acbc2f18bf/torch/csrc/utils/tensor_memoryformats.cpp#L33

3. Decrease the refcnt. (refcnt = 1)
https://github.com/pytorch/pytorch/blob/d1bb420fb1087d680b7ad526536e14acbc2f18bf/torch/csrc/utils/tensor_memoryformats.cpp#L35

4. An exception is thrown without decreasing the refcnt.
https://github.com/pytorch/pytorch/blob/d1bb420fb1087d680b7ad526536e14acbc2f18bf/torch/csrc/utils/tensor_memoryformats.cpp#L36

cc @ezyang @gchanan @zou3519
TorchScript attempts to compile dead branch of torch.jit.is_scripting
Labels: oncall: jit

### 🐛 Describe the bug

Consider the following code. The `else` branch of the condition in `get_context` evaluates to `False` when scripting. Running this code still produces an exception.

```python
import torch

meow = 1239

def get_context():
  if torch.jit.is_scripting():
    print('hi')
  else:
    global meow
    meow = 9123
    return meow

if __name__ == '__main__':
  x = torch.jit.script(get_context)
  print(x.code)
```

Output:

```python
torch.jit.frontend.UnsupportedNodeError: global variables aren't supported:
  File "/mnt/data/lmnt/code/tacotron/src/lmnt/tacotron/context.py", line 9
    print('hi')
  else:
    global meow
    ~~~~~~ <--- HERE
    meow = 9123
    return meow
```

This is the output of the script after removing the `global meow` line:

```python
def get_context() -> NoneType:
  print("hi")
  return None
```

Note how the dead branch is eliminated *after* scripting. Instead, the dead branch should be eliminated before attempting to compile it.

There are workarounds to the current behavior (e.g. move the else clause into a separate function with a `@torch.jit.unused` annotation) but they aren't ergonomic and often ruin the code flow.

### Versions

Any version of PyTorch
`addmv, mv` will trigger INTERNAL ASSERT FAILED when input requiring grad
Labels: module: autograd, triaged, actionable

### 🐛 Describe the bug

`addmv` will trigger INTERNAL ASSERT FAILED when input requiring grad

```python
import torch

def addmv(input):
    mat = torch.randint(-1, 1, [2, 3], dtype=torch.int8)
    vec = torch.randint(-1, 1, [3], dtype=torch.int8)
    return torch.addmv(input, mat, vec)

input_normal = torch.rand([2], dtype=torch.float32)
addmv(input_normal)
print('normal pass')
# normal pass

input_with_grad = input_normal.clone().requires_grad_()
addmv(input_with_grad)
# RuntimeError: isDifferentiableType(variable.scalar_type())INTERNAL ASSERT FAILED at "/Users/distiller/project/pytorch/torch/csrc/autograd/functions/utils.h":65, please report a bug to PyTorch. 
```

`mv` will trigger INTERNAL ASSERT FAILED when input requiring grad

```python
import torch

vec = torch.randint(0, 8, [10], dtype=torch.uint8)
tensor = torch.rand([0, 10], dtype=torch.complex64, requires_grad=True)
torch.mv(tensor, vec)
# RuntimeError: isDifferentiableType(variable.scalar_type()) INTERNAL ASSERT FAILED at "/opt/conda/conda-bld/pytorch_1654585902583/work/torch/csrc/autograd/functions/utils.h":65, please report a bug to PyTorch.
```

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
FSDP should work for model outputs that are dataclasses
Labels: oncall: distributed, triaged, pt_distributed_rampup, module: fsdp

### 🚀 The feature, motivation and pitch

FSDP currently supports dict/OrderedDict, tuple, list of tensor outputs, although we've seen some use cases also want to output `dataclass` instances from their model. This currently breaks in `_apply_to_tensors` when registering backwards hooks, we should add this support for dataclasses.

### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
`Could not start gRPC server` flakiness in XLA tests
Labels: triaged, module: xla

For some examples, see [here](https://hud.pytorch.org/failure/RuntimeError%3A%20tensorflow%2Fcompiler%2Fxla%2Fxla_client%2Fxrt_local_service.cc%3A56%20%3A%20Check%20failed%3A%20tensorflow%3A%3ANewServer(server_def%2C%20%26server_)%20%3D%3D%20%3A%3Atensorflow%3A%3AStatus%3A%3AOK()%20(UNKNOWN%3A%20Could%20not%20start%20gRPC%20server%20vs.%20OK)). 

Can we add some retries or something to this test?

cc @bdhirsh
`torch.utils.benchmark.examples.blas_compare` can not be parsed by Python-3.7 runtime
Labels: triaged, module: benchmark

### 🐛 Describe the bug

Attempt to `python3 -c "import torch.utils.benchmark.examples.blas_compare"` fails with
```
File "/opt/conda/lib/python3.7/site-packages/torch/utils/benchmark/examples/blas_compare.py", line 35, in <module>
     _WORKER_POOL: queue.Queue[Tuple[str, str, int]] = queue.Queue()
 TypeError: 'type' object is not subscriptable
```
See [this](https://github.com/pytorch/pytorch/runs/6493890839?check_suite_focus=true) for example

### Versions

nightly
strange behaviour in torch.div
Labels: high priority, triaged

### 🐛 Describe the bug

The following code 
```
import torch
x = torch.tensor([1e+308, 0., 0., 0., 0., 0., 0.], dtype=torch.float64)
y = torch.tensor([0.5, 1., 1., 1., 1., 1., 1.], dtype=torch.float16)
torch.div(x, y, rounding_mode='floor')
```
gives `tensor([inf, 0., 0., 0., 0., 0., 0.], dtype=torch.float64)`, as I expect. However, appending another `0` to `x` and another `1` to `y` seems to change the behaviour of div:
```
x = torch.tensor([1e+308, 0., 0., 0., 0., 0., 0., 0.], dtype=torch.float64)
y = torch.tensor([0.5, 1., 1., 1., 1., 1., 1., 1.], dtype=torch.float16)
torch.div(x, y, rounding_mode='floor')
```
gives `tensor([nan, 0., 0., 0., 0., 0., 0., 0.], dtype=torch.float64)`.

Why does the first element of the result change from `inf` to `nan` just because I made `x` and `y` longer?

### Versions

1.11.0

cc @ezyang @gchanan @zou3519
torchrun leads to `ModuleNotFoundError: No module named 'tensorboard'`, but python -m torch.distributed.launch is ok
Labels: triaged, oncall: r2p

### 🐛 Describe the bug

When I tried to use torchrun to launch the job
```
torchrun --nproc_per_node=4 --master_port=12346 train_ours.py
```
It told me that `ModuleNotFoundError: No module named 'tensorboard'`, but actually I have installed it.
```
[stderr]    from torch.utils.tensorboard import SummaryWriter
[stderr]  File "/home/aiscuser/.local/lib/python3.7/site-packages/wrapt/importer.py", line 176, in _exec_module
[stderr]    self.loader.exec_module(module)
[stderr]  File "/opt/miniconda/lib/python3.7/site-packages/torch/utils/tensorboard/__init__.py", line 1, in <module>
[stderr]    import tensorboard
[stderr]ModuleNotFoundError: No module named 'tensorboard'
```
I used the old command to launch, everything is ok ....
`python -m torch.distributed.launch --nproc_per_node=4 --master_port=12346 train_ours.py`


### Versions
```
torch                   1.10.1+cu111
torchaudio              0.10.1+rocm4.1
torchvision             0.11.2+cu111
tensorboard             2.9.0
tensorboard-data-server 0.6.1
tensorboard-plugin-wit  1.8.1
tensorboardX            2.5
```

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
Adding Vulkan Support 
Labels: triaged, module: vulkan

### 🐛 Describe the bug

To Reproduce :-

cd PYTORCH_ROOT
USE_VULKAN=1 USE_VULKAN_SHADERC_RUNTIME=1 USE_VULKAN_WRAPPER=0 python setup.py install



Getting Error :-
Could NOT find Shaderc (missing: GOOGLE_SHADERC_INCLUDE_DIRS GOOGLE_SHADERC_LIBRARIES) 
CMake Error at cmake/VulkanDependencies.cmake:117 (message):
  USE_VULKAN: Shaderc not found in VULKAN_SDK

But Vulkan SDK has a folder named Shaderc but it doesn't contain  GOOGLE_SHADERC_INCLUDE_DIRS GOOGLE_SHADERC_LIBRARIES.

![Screenshot from 2022-05-18 13-56-46](https://user-images.githubusercontent.com/83056874/168993980-5410fb58-ba65-4d3d-ae3f-dbeac5cfe411.png)


### Versions

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: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.19.6
Libc version: glibc-2.27

Python version: 3.9.12 (main, Apr  5 2022, 06:56:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.4.0-110-generic-x86_64-with-glibc2.27
Is CUDA available: N/A
CUDA runtime version: Could not collect
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: N/A

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.5
[pip3] numpydoc==1.2
[conda] blas                      1.0                         mkl  
[conda] magma-cuda110             2.5.2                         1    pytorch
[conda] mkl                       2021.4.0           h06a4308_640  
[conda] mkl-include               2022.0.1           h06a4308_117  
[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.21.5           py39he7a7128_1  
[conda] numpy-base                1.21.5           py39hf524024_1  
[conda] numpydoc                  1.2
FSDP: enhanced shared parameter support
Labels: oncall: distributed, triaged, module: fsdp

### 🚀 The feature, motivation and pitch

As of 1.12, only limited shared param support exists for FSDP, i.e., they must be part of the same FSDP unit, user cannot shared parameters if their respective modules end up being wrapped as part of different FSDP units. Creating this issue to track full support.

### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
PrimTorch refs do not match argument naming with their PyTorch counterparts
Labels: triaged, module: primTorch

### 🐛 Describe the bug

```
>>> import torch
>>> torch.nn.functional.elu(input=torch.randn(2))
tensor([-0.3709,  0.5241])
>>> import torch._refs.nn.functional
>>> torch._refs.nn.functional.elu(input=torch.randn(2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/raid/ezyang/pytorch-scratch2/torch/_prims/wrappers.py", line 93, in _fn
    bound = sig.bind(*args, **kwargs)
  File "/scratch/ezyang/pytorch-scratch2-env/lib/python3.8/inspect.py", line 3025, in bind
    return self._bind(args, kwargs)
  File "/scratch/ezyang/pytorch-scratch2-env/lib/python3.8/inspect.py", line 2940, in _bind
    raise TypeError(msg) from None
TypeError: missing a required argument: 'a'
```

Unfortunately because nothing in PyTorch is positional-only, the argument names are public API

### Versions

master

cc @ezyang @mruberry @ngimel
PrimTorch decomps for random functions
Labels: triaged, module: random, ezyang's list, module: primTorch

I'd like to see primtorch decompositions that map all randomness to a single function (perhaps aten.rand()).

The snag: I want the same answer as eager mode.  Same as eager mode means I can check correctness.  It is also a better experience for users.

The ones I am seeing in torchbench models are:
- [ ] dropout (already exists in torch._decomp, but different(?) answer than eager)
- [ ] randn
- [ ] randperm

cc @pbelevich @ezyang @mruberry @ngimel @Lezcano @peterbell10 @Chillee
PyTorch fails to build on gcc 12 due to gloo
Labels: module: build, triaged, module: third_party

### 🐛 Describe the bug

```
/home/gaoxiang/pytorch-nvfuser-master/third_party/gloo/gloo/transport/tcp/device.cc:151:39: error: implicit instantiation of undefined template 'std::array<char, 64>'
      std::array<char, HOST_NAME_MAX> hostname;
```

Adding `#include <array>` to that file should fix the problem. But looks like the `gloo` submodule haven't been updated for long time, so I don't know how this issue should be fixed.

### Versions

```
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: Arch Linux (x86_64)
GCC version: (GCC) 12.1.0
Clang version: 13.0.1
CMake version: version 3.23.1
Libc version: glibc-2.35

Python version: 3.10.4 (main, Mar 23 2022, 23:05:40) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.17.6-arch1-1-x86_64-with-glibc2.35
Is CUDA available: N/A
CUDA runtime version: 11.6.124
GPU models and configuration: 
GPU 0: NVIDIA GeForce RTX 3090
GPU 1: NVIDIA GeForce RTX 2080 Ti

Nvidia driver version: 510.68.02
cuDNN version: Probably one of the following:
/usr/lib/libcudnn.so.8.4.0
/usr/lib/libcudnn_adv_infer.so.8.4.0
/usr/lib/libcudnn_adv_train.so.8.4.0
/usr/lib/libcudnn_cnn_infer.so.8.4.0
/usr/lib/libcudnn_cnn_train.so.8.4.0
/usr/lib/libcudnn_ops_infer.so.8.4.0
/usr/lib/libcudnn_ops_train.so.8.4.0
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch-ucc==1.0.0
[pip3] torchani==2.2
[pip3] torchvision==0.2.2.post3
[conda] Could not collect

```

cc @malfet @seemethere