gopikrsmscs/torch-issues huggingface dataset:
add github check that diffs generated code
Labels: triaged, module: infra, module: codegen

### 🚀 The feature, motivation and pitch

PyTorch relies heavily on generated code. We should make the experience around that in CI better for authors and reviewers both.

We should add a check that generates all the code at the base ref and the head ref and diffs them. If there are differences we should add a link to a page that renders the diffs and perhaps also add a label on the PR.

We may want to go even further by requiring review and approval of diffs to generated code through some mechanism.

### Alternatives

An alternative could be to provide a command that authors and reviewers both can run to generate and compare the generated code, but I think it's even better if that is done automatically as proposed.

### Additional context

_No response_

cc @ezyang @bhosmer @bdhirsh
Add compile option -Werror=return-type compile error
Labels: module: build, triaged, actionable

### 🐛 Describe the bug

When I add -Werror=return-type to the compilation option, the following error occurs during compilation.
```
/data/vcpkg/buildtrees/libtorch/src/v1.12.1-d15308d103.clean/aten/src/ATen/native/Convolution.cpp: In function ‘at::Tensor at::native::_convolution_mode(const at::Tensor&, const at::Tensor&, const c10::optional<at::Tensor>&, at::IntArrayRef, c10::string_view, at::IntArrayRef, int64_t)’:
/data/vcpkg/buildtrees/libtorch/src/v1.12.1-d15308d103.clean/aten/src/ATen/native/Convolution.cpp:920:1: error: control reaches end of non-void function [-Werror=return-type]
  920 | }
      | ^
cc1plus: some warnings being treated as errors
```

### Versions

The version I am using is 1.12.1

cc @malfet @seemethere
[Tensor Parallel] Clarify docs
Labels: oncall: distributed

### 📚 The doc issue

Some enhancements when reading through tensor parallel docs: https://github.com/pytorch/pytorch/blob/main/torch/distributed/tensor/parallel/api.py#L35

- Example should include DeviceMesh creation
- > ``PairwiseParallel`` comes with constraints for now. -->  we should add a description of what sort of constraints these are.
- 

### Suggest a potential alternative/fix

_No response_

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Revive multigpu testing
Labels: module: ci, triaged

### 🐛 Describe the bug

@ngimel brought to my attention, that we do not have multigpu testing for `test_ops` and `test_jit`
It would be good idea to move all test decorated with `@needsMultiGPU` to a separate file and create its own periodic config for multigpu tests

### Versions

CI

cc @seemethere @pytorch/pytorch-dev-infra
Copying an MPS tensor to a CPU tensor using a for loop fails
Labels: triaged, module: mps

### 🐛 Describe the bug

A simple copy from an MPS tensor to a CPU tensor leads to only the first element of the CPU tensor being modified and being assigned the last value of the MPS tensor.

Simple example:
```python
import torch
mv = torch.arange(5,device=torch.device('mps'),dtype=torch.float32)
cv = torch.zeros(5,dtype=torch.float32)
for i in range(5):
    cv[i] = mv[i]
print(f'mv={mv.cpu().numpy()}')
print(f'cv={cv.numpy()}')
```
leading to
```
mv=[0. 1. 2. 3. 4.]
cv=[4. 0. 0. 0. 0.]
```

Results are even stranger if the dtypes are different:
```python
import torch
mv = torch.arange(5,device=torch.device('mps'),dtype=torch.int32)
cv = torch.zeros(5,dtype=torch.float32)
for i in range(5):
    cv[i] = mv[i]
print(f'mv={mv.cpu().numpy()}')
print(f'cv={cv.numpy()}')
```
leading to
```
mv=[0 1 2 3 4]
cv=[6.e-45 0.e+00 0.e+00 0.e+00 0.e+00]
```

### Versions

PyTorch version: 2.1.0.dev20230422
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.3.1 (arm64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: version 3.26.3
Libc version: N/A

Python version: 3.11.2 (main, Mar 15 2023, 21:30:06) [Clang 14.0.0 (clang-1400.0.29.202)] (64-bit runtime)
Python platform: macOS-13.3.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

CPU:
Apple M2 Pro

Versions of relevant libraries:
[pip3] numpy==1.24.1
[pip3] torch==2.1.0.dev20230422
[pip3] torchaudio==2.1.0.dev20230424
[pip3] torchvision==0.16.0.dev20230424
[conda] Could not collect

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
torch.cuda.is_available() crashes python in systems with disabled gpu
Labels: module: crash, module: cuda, triaged, module: edge cases

### 🐛 Describe the bug

Recently, whenever I call torch.cuda.is_available(), my python interpreter suddenly crashes. However, this only happens when using it in the "wild", when calling it in PyCharm, everything works fine.

It might be because of the laptop I'm using, which disables the nvidia gpu when in battery mode, however, it worked before. _This crash only happens in battery mode with the disabled gpu._ 
**Although this might be a strangely unusual setup, this call should still not crash the entire interpreter.**

This happened in torch 1.13 as well as in 2.0.0.
I updated the python interpreter as well as all packages, but it did not help so far.
I'm using python 3.10.11 in a venv with CUDA 11.7.1 on Win11.

I also tried surrounding the call with try-except, to catch possible uncaught exceptions, however with no success.

Whenever I execute the file containing the cuda-check, or type it directly into the interpreter, the process crashes and exits, without any further message, except for the exit code: -1073740791 (0xC0000409).

```
import torch.cuda
torch.cuda.is_available()
```

### Versions

```
PyTorch version: 2.0.0+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 Home
GCC version: Could not collect
Clang version: Could not collect
CMake version: version 3.24.0
Libc version: N/A

Python version: 3.10.11 (tags/v3.10.11:7d4cc5a, Apr  5 2023, 00:38:17) [MSC v.1929 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.22621-SP0
Is CUDA available: True
CUDA runtime version: 11.7.99
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1650 with Max-Q Design
Nvidia driver version: 531.61
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.7\bin\cudnn_ops_train64_8.dll
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture=9
CurrentClockSpeed=3201
DeviceID=CPU0
Family=107
L2CacheSize=4096
L2CacheSpeed=
Manufacturer=AuthenticAMD
MaxClockSpeed=3201
Name=AMD Ryzen 7 5800HS with Radeon Graphics
ProcessorType=3
Revision=20480

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] torch==2.0.0+cu117
[pip3] torchvision==0.15.1+cu117
[conda] Could not collect


```

cc @ngimel
Group Norm crashes on Apple M1/MPS devices for versions 2.0+
Labels: needs reproduction, triaged, module: regression, module: mps

### 🐛 Describe the bug

I ran the following notebook locally under 3 versions of PyTorch (1.13.1, 2.0.0, and local build of main 2.1.0a0+git466adab) https://colab.research.google.com/drive/1gxdkgRVfM55zihY9TFLja97cSVZOZq2B?usp=sharing 

I isolated the error to the group norm layer (nn.GroupNorm(n_groups, out_channels)). With a group norm (regardless of if the network is on cpu or sent to mps) the very first loss.backwards() causing the python kernel to crash. If you swap this layer out with a batch norm or instance norm, training proceeds as normal

### Versions

Collecting environment information...
PyTorch version: 2.1.0a0+git466adab
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.3.1 (arm64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: version 3.22.1
Libc version: N/A

Python version: 3.8.16 (default, Mar  1 2023, 21:18:45)  [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-13.3.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

CPU:
Apple M1 Max

Versions of relevant libraries:
[pip3] numpy==1.23.5
[pip3] torch==2.1.0a0+git466adab
[conda] numpy                     1.23.5                   pypi_0    pypi
[conda] torch                     2.1.0a0+git466adab           dev_0    <develop>

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
`print` statement causes inplace error
Labels: module: autograd, triaged, needs design

### 🐛 Describe the bug

Reported in: https://discuss.pytorch.org/t/error-with-view-no-grad-and-inplace-modify/173082
but I couldn't find the created GitHub issue and the author didn't follow up.

Code to reproduce the issue:
```python
net = nn.Sequential(
    nn.Linear(10, 10),
    nn.ReLU(),
    nn.Linear(10, 10),
    nn.ReLU(),
    nn.Linear(10, 10),
    nn.ReLU(),
)

with torch.no_grad():
  for param in net.parameters():
    for j in param.flatten():
        #print("current j", j)
        j += 1
```
Comment the `print` statement in and the code will fail with:
```python
RuntimeError: A view was created in no_grad mode and its base or another view of its base has been modified inplace with grad mode enabled. Given that this use case is ambiguous and error-prone, it is forbidden. You can clarify your code by moving both the view and the inplace either both inside the no_grad block (if you don't want the inplace to be tracked) or both outside (if you want the inplace to be tracked).
```

I would assume the inplace operation is allowed as it's in a `no_grad` block and no computation graph was ever created.

Also, maybe related to: https://discuss.pytorch.org/t/old-problem-but-strange-things-trying-to-backward-through-the-graph-a-second-time/178369

but no executable code snippet was posted yet.



### Versions

Reproduced in a nightly build: `2.1.0.dev20230407+cu118`.

CC @albanD as we talked about this issue before.

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
[inductor] Autotuning leads to non determinism
Labels: triaged, oncall: pt2, module: inductor

### 🐛 Describe the bug

https://github.com/pytorch/pytorch/pull/99851 disables autotuning when torch.use_deterministic_algorithms are ON.

However, we should due diligence to see if we can remove or alteast reduce non-determinism with autotuning. 

### Error logs

_No response_

### Minified repro

_No response_

### Versions

NA

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
benchmarks/dynamo/ci_expected_accuracy/update_expected.py truncates file if only one shard succeeds
Labels: triaged, module: benchmark, oncall: pt2

### 🐛 Describe the bug

If you run benchmarks/dynamo/ci_expected_accuracy/update_expected.py on a run where one shard failed for some reason, it will delete all the entries associated with that shard. We should instead merge the entries from the shard

### Versions

master

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh
ciflow/inductor should run both inference and training even if inference fails
Labels: module: ci, triaged, module: inductor

### 🐛 Describe the bug

Otherwise `benchmarks/dynamo/ci_expected_accuracy/update_expected.py` cannot get all the updates; you have to run once, update, and then run it again

### Versions

master

cc @seemethere @malfet @pytorch/pytorch-dev-infra @soumith @voznesenskym @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
Deprecate torch.distributed.algorithms._optimizer_overlap
Labels: oncall: distributed

### 🚀 The feature, motivation and pitch

After a discussion with @rohan-varma, we agreed we should deprecate and remove [torch.distributed.algorithms._optimizer_overlap](https://github.com/pytorch/pytorch/blob/7d2a18da0b3427fcbe44b461a0aa508194535885/torch/distributed/algorithms/_optimizer_overlap/optimizer_overlap.py) in favor of [torch.distributed.optim.apply_optimizer_in_backward](https://github.com/pytorch/pytorch/blob/7d2a18da0b3427fcbe44b461a0aa508194535885/torch/distributed/optim/apply_optimizer_in_backward.py).

This deprecation would involve:
- [ ] Adding a deprecation warning for its usage
- [ ] Offboarding any use cases to use the other API
- [ ] Removing the extra code that came along with it, for example any documentation and helpers like [torch.distributed.algorithms.ddp_comm_hooks](https://github.com/pytorch/pytorch/blob/7d2a18da0b3427fcbe44b461a0aa508194535885/torch/distributed/algorithms/ddp_comm_hooks/optimizer_overlap_hooks.py)

### Alternatives

_No response_

### Additional context

_No response_

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Can the CUDA device LUID be exposed as part of _CudaDeviceProperties?
Labels: module: cuda, triaged, enhancement, actionable, needs design

### 🚀 The feature, motivation and pitch

CUDA devices can be ordered in a few different ways (FASTEST_FIRST, PCI_BUS_ID). The device LUID is the more modern way of describing a GPU in a unique way. It's particularly useful when using CUDA along with other APIs such as Vulkan or DirectX.
Can the LUID that the cudaDeviceProp structure contains be made visible in _CudaDeviceProperties as well?
https://docs.nvidia.com/cuda/cuda-runtime-api/structcudaDeviceProp.html#structcudaDeviceProp_1b1fe931f3f41d1b97c8679c8b15d94e3

Thanks

### Alternatives

_No response_

### Additional context

_No response_

cc @ngimel
Many models are failing on periodic dynamic shape benchmark tests dynamic_aot_eager
Labels: triaged, oncall: pt2, module: dynamic shapes

### 🐛 Describe the bug

For example, https://hud.pytorch.org/pytorch/pytorch/commit/ab0a8215bb73c508ecfaabead6f3118beef2547f.  There are more than one root cause here I think.  I have moved the test to unstable in the meantime https://github.com/pytorch/pytorch/pull/99895

### Versions

PyTorch CI

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
Dynamo config patching in our code is brittle
Labels: triaged, oncall: pt2, module: dynamo, module: export

### 🐛 Describe the bug

Concretely, the other day, I was trying to change the default setting of `assume_static_by_default` for export only: https://github.com/pytorch/pytorch/pull/99554 The easiest way to do this was to modify _dynamo.export to patch this to False on entry.

However, this resulted in something very awkward: it's now *no longer possible* to override this setting via external configuration! Because the config setting always gets overwritten by the patch on the inside.

In general, it's awkward to have config settings that default one way for eager and another export. It would be nice to figure out some robust mechanism for doing this

### Versions

master

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh @voznesenskym @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire
Logs output_code and inductor do not interact as expected
Labels: module: logging, triaged

### 🐛 Describe the bug

As discussed in https://github.com/pytorch/pytorch/issues/94788#issuecomment-1515441713, setting `inductor` does not generate the `output_code` artefact. This goes against the definition that `output_code` is an artifact owned by `inductor`. This issue lead to the discussion in https://github.com/pytorch/pytorch/pull/99038 of wanting to log the output folder at two different levels, which signals that there's something a bit off about the whole thing. The better way of controlling this would be via logging the output file and the code at two different verbosity levels.

cc @mlazos @kurtamohler 

### Versions

master
NTK notebook calculates wrong object - wrong output dimensions
Labels: triaged, module: functorch

### 📚 The doc issue

The notebook given in https://pytorch.org/functorch/stable/notebooks/neural_tangent_kernels.html does not calculate the NTK - the output depends on the size of the input tensors instead of the size of the network's input. The NTK should be a n_in x n_in x n_out x n_out matrix (https://en.wikipedia.org/wiki/Neural_tangent_kernel), where n_in/n_out are the sizes of the network's inputs/outputs. 

### Suggest a potential alternative/fix

_No response_

cc @zou3519 @Chillee @samdow @soumith @kshitij12345 @janeyx99
When backend is nccl, the distribution group type generated by Pytorch 2.0 shoule be ProcessGroupNCCL, but is ProcessGroup
Labels: oncall: distributed

### 🐛 Describe the bug

Hi, I have discovered an issue. The default distribution group type generated by Pytorch 2.0 is ProcessGroup, while in Pytorch version 1.8, it is ProcessGroupNCCL. By debugging the code, it was found that the return values of the code in Pytorch 2.0 and 1.8 are different
Pytorch 2.0
```
import torch
issubclass(torch._C._distributed_c10d.ProcessGroupNCCL, torch._C._distributed_c10d.ProcessGroup)
False
```
Pytorch 1.8
```
import torch
issubclass(torch._C._distributed_c10d.ProcessGroupNCCL, torch._C._distributed_c10d.ProcessGroup)
True
```

The above issue will cause problems with this function “_new_process_group_helper”:
```
        if issubclass(type(backend_class), ProcessGroup):
            pg = backend_class
            break
```


cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
cuda.is_available() error
Labels: module: cuda, triaged

I test pytorch on a server with epyc 7742 and 8*A100 40G, when print torch.cuda.is_available() there is no output and even can't kill the python process with Ctrl+C, how can i solve this bug without update the driver version? I try install another version cuda like 11.1 or 11.0.2 but still no result.
Hope your reply!
Thanks!

- PyTorch:
- How you installed PyTorch: conda install pytorch==1.7.1 torchvision==0.8.2 torchaudio==0.7.2 cudatoolkit=11.0 -c pytorch
- OS: Ubuntu18.04
- PyTorch version:1.7.1
- Python version:3.8.3
- CUDA/cuDNN version: cuda11.0.3
- GPU models and configuration: 8*A100
- Nvidia Driver:450.51.06


cc @ngimel
AOTAutograd/Inductor file system cache
Labels: triaged, oncall: pt2, module: inductor

### 🐛 Describe the bug

I was playing around with implementing a kernel using torch.compile(dynamic=True) to guarantee low memory usage (and also because I needed an unusual reduction, xor_sum, which wasn't in PyTorch proper.)

```
    # Use of torch.compile is mandatory for (1) good memory usage
    # and (2) xor_sum implementation
    @torch.compile(dynamic=True)
    def kernel(x):
        # The randint calls are carefully written to hit things we
        # have lowerings for in inductor.  Lack of unsigned 32-bit integer
        # is a pain.
        a = torch.randint(
            -2**31, 2**31,
            x.shape, device=x.device, dtype=torch.int32
        ).abs()
        a = ((a % (2**31-1)) + 1).long()
        b = torch.randint(
            -2**31, 2**31,
            x.shape, device=x.device, dtype=torch.int32
        ).abs().long()
        # This is a standard shift-multiply universal hash family
        # plus xor sum hash, using Philox to generate random numbers.
        # Our Philox RNG is not deterministic across devices so
        # don't use this for stable hashing.
        #   
        # This assumes fixed length so you're also obligated to bucket
        # by the length of tensor as well
        return prims.xor_sum(
            (a * x + b).int(),
            [0]
        )
```

On a warm Triton cache, this still takes a good 10s to compile the kernel for the first time on any given process invocation. This is way too slow, esp since once I'm done working on the kernel, it probably will never change. A good file system cache would improve this situation quite a bit.

### Versions

master

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh @voznesenskym @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
`cat` gradgrad tests failing
Labels: module: autograd, triaged, module: edge cases

## Issue description

Previously `cat` grad tests were surprisingly skipped here:
              
https://github.com/pytorch/pytorch/blob/e63c502baa4a6f2109749984be701e722b3b7232/torch/testing/_internal/common_utils.py#L4371-L4372

And the following tests are failing after removing the skip:

```
test/test_ops_gradients.py::TestBwdGradientsCPU::test_fn_gradgrad_cat_cpu_float64
test/test_ops_gradients.py::TestBwdGradientsCPU::test_fn_gradgrad_cat_cpu_complex128
```

```
# RuntimeError: The size of tensor a (25) must match the size of tensor b (0) at non-singleton dimension 0.
```

which is caused by the below input sample:

https://github.com/pytorch/pytorch/blob/6580b160d35a75d5ceebf376d55422376d0c0d2c/torch/testing/_internal/common_methods_invocations.py#L2043

Added these tests to xfail in #99596

## Version

On master

cc @ezyang @gchanan @zou3519 @albanD @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
torch.multinomial() always returns [0] using MPS
Labels: triaged, module: mps

### 🐛 Describe the bug

Using MPS, torch.multinomial() always return [0], even when the probability is 0.

It works as expected on CPU:
```
import torch

In [1]: x = torch.tensor([0.5, 0.5], dtype=torch.float, device='cpu')
    ...: print(set(torch.multinomial(x, 1, True).item() for i in range(100)))
{0, 1}

In [2]: x = torch.tensor([0, 0.5], dtype=torch.float, device='cpu')
    ...: print(set(torch.multinomial(x, 1, True).item() for i in range(100)))
{1}
```

But on MPS, it always return [0].

```
In [3]: x = torch.tensor([0.5, 0.5], dtype=torch.float, device='mps:1')
   ...: print(set(torch.multinomial(x, 1, True).item() for i in range(100)))
{0}

In [4]: x = torch.tensor([0, 0.5], dtype=torch.float, device='mps:1')
    ...: print(set(torch.multinomial(x, 1, True).item() for i in range(100)))
{0}

In [5]: torch.multinomial(x, 1, True)
Out[5]: tensor([0], device='mps:0')
```

I am actually quite new to torch, so please let me know if I misunderstood anything.


### Versions

PyTorch version: 2.0.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.6.3 (x86_64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.202)
CMake version: version 3.22.4
Libc version: N/A

Python version: 3.9.6 (default, Jul  7 2021, 12:22:14)  [Clang 12.0.5 (clang-1205.0.22.9)] (64-bit runtime)
Python platform: macOS-12.6.3-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Max

Versions of relevant libraries:
[pip3] numpy==1.23.5
[pip3] torch==2.0.0
[conda] No relevant packages

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
Automatic broadcasting for sparse csr tensors
Labels: module: sparse, triaged

### 🚀 The feature, motivation and pitch

Hey, would it be possible to add broadcasting to sparse csr tensors.


```python
import torch
input = torch.randn(6,6).to_sparse_csr()
bias = torch.tensor([[1,2,0,0,3,2]]).t().to_sparse_csr()
input.to_dense() + bias.to_dense() # working
input + bias.to_dense() # not working
input.to_dense() + bias # not working
input + bias # not working
```



### Alternatives

While elementwise dense matrix multplication/addition broadcasting is supported, it is not supported for sparse (csr) tensors.
Could that be added?

### Additional context

_No response_

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer
Apple metal (MPS)  device returning incorrect keypoints for YOLOv8 pose estimation model 
Labels: high priority, oncall: binaries, oncall: releng, triaged, module: correctness (silent), module: mps

### 🐛 Describe the bug

I'm encountering an issue with the YOLOv8 pose estimation model inference using the MPS model. The model is returning incorrect key points. However, when I use the same method and code on the CPU, the key points are correct. I believe the issue may be related to the Apple Metal library. From my research, it seems to be causing the error. The bounding boxes detection seems to be working fine, but there's an issue with calculating the key points. Could you please help me solve this problem?

```python 
import cv2
import numpy as np
from ultralytics import YOLO

cv2.namedWindow("mps_test",cv2.WINDOW_NORMAL)
image = cv2.imread("pose_test.jpeg")
model = YOLO('yolov8s-pose.pt')  # load an official model

results = model(source=image,device="cpu",conf=0.6)
#results = model(source=image,device="mps",conf=0.6)

result_image = results[0].plot()

cv2.imshow("cpu_test", result_image)
cv2.waitKey(0)
cv2.destroyAllWindows()
```
Output With "MPS" (apple metal)
<img width="1168" alt="Screenshot 2023-04-19 at 15 54 42" src="https://user-images.githubusercontent.com/46287166/233779812-87e363e1-b37e-4cbe-b628-5952c3bfc35f.png">

Output With "CPU"

<img width="1212" alt="Screenshot 2023-04-19 at 16 18 57" src="https://user-images.githubusercontent.com/46287166/233779839-1fb70ff8-2bc4-43db-b270-caa495e19921.png">




### Versions
Macbook Air m1 chip 
Metal: Version: 306.2.4
XCode:14.3
Macos Ventura:13.0
ultralytics Version: 8.0.81
Python Version: 3.10.8
Torch Version: 2.1.0.dev20230417
Opencv Version: 4.7.0.72


cc @ezyang @gchanan @zou3519 @seemethere @malfet @kulinseth @albanD @DenisVieriu97 @razarmehr @abhudev
Cannot compile torch 1.10 in CentOS 7.3
Labels: triaged

### 🐛 Describe the bug

I tried to compile PyTorch 1.10 on CentOS, but after configuring the system environment, I always got compilation errors as follows. I found that the gcc version was incorrect and could not be upgraded on CentOS. How can I solve this?

![image](https://user-images.githubusercontent.com/73052387/233765855-9ad9cb96-ee85-41a8-829e-2bd4aeec9d37.png)


### Versions

PyTorch version: 1.10.1
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: (conda-forge gcc 12.2.0-19) 12.2.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.17

Python version: 3.9.16 (main, Mar  8 2023, 14:00:05)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-3.10.0-514.el7.x86_64-x86_64-with-glibc2.17
Is CUDA available: True
CUDA runtime version: 10.2.89
CUDA_MODULE_LOADING set to: 
GPU models and configuration: GPU 0: Tesla T4
Nvidia driver version: 440.33.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                12
On-line CPU(s) list:   0-11
Thread(s) per core:    2
Core(s) per socket:    6
座：                 1
NUMA 节点：         1
厂商 ID：           GenuineIntel
CPU 系列：          6
型号：              158
型号名称：        Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
步进：              10
CPU MHz：             3155.250
BogoMIPS：            6400.00
虚拟化：           VT-x
L1d 缓存：          32K
L1i 缓存：          32K
L2 缓存：           256K
L3 缓存：           12288K
NUMA 节点0 CPU：    0-11

Versions of relevant libraries:
[pip3] numpy==1.23.5
[pip3] torch==1.10.1
[pip3] torchaudio==0.10.1
[pip3] torchvision==0.11.2
[conda] blas                      1.0                         mkl  
[conda] cudatoolkit               10.2.89              hfd86e86_1  
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640  
[conda] mkl-include               2023.1.0         h06a4308_46342  
[conda] mkl-service               2.4.0            py39h7f8727e_0  
[conda] mkl_fft                   1.3.1            py39hd3c417c_0  
[conda] mkl_random                1.2.2            py39h51133e4_0  
[conda] numpy                     1.23.5           py39h14f4228_0  
[conda] numpy-base                1.23.5           py39h31eccc5_0  
[conda] pytorch                   1.10.1          py3.9_cuda10.2_cudnn7.6.5_0    pytorch
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] torchaudio                0.10.1               py39_cu102    pytorch
[conda] torchvision               0.11.2               py39_cu102    pytorch
Deformable Convolution export to onnx
Labels: module: onnx, triaged

### Deformable Convs in onnx export

Dear Torch Team,

Is there a possibilty that the torch.onnx.export() function gets updated so that it support the deformable convolution layer that is now supported in the latest opset (version 19) of ONNX.
I believe that adding support for deformable convolutions in torch.onnx.export() would greatly enhance the functionality and versatility of the export possibilities.

Nick
cuda 12.0 support request for building pytorch from source code
Labels: module: build, module: cuda, triaged, enhancement

### 🚀 The feature, motivation and pitch

Motivation:
      It does support cuda 12.1, but it does not support cuda 12.0
     According to the doc: https://github.com/pytorch/pytorch#from-source , the magma-cuda* that does not match the CUDA version 12.0 from https://anaconda.org/pytorch/repo. Only magma-cuda121 can be found, no magma-cuda120

feature: please support cuda 12.0 for building pytorch from source code

Thank you!

### Alternatives

_No response_

### Additional context

_No response_

cc @malfet @seemethere @ngimel
no-duplicate-decl-specifier as a invalid compile flag for CXX in GCC
Labels: module: build, module: rocm, triaged

### 🐛 Describe the bug

[cmake/Dependencies.cmake](https://github.com/pytorch/pytorch/blob/9861ec9785b53e71c9affd7d268ef7073eb1c446/cmake/Dependencies.cmake#L1272) sets -Wno-duplicate-decl-specifier for HIP_CXX_FLAGS. at least for GCC 12 this is not a valid compile flag for c++ translation units causeing lots of  `cc1plus: warning: command-line option ‘-Wno-duplicate-decl-specifier’ is valid for C/ObjC but not for C++` warnings

### Versions

9861ec9785b53e71c9affd7d268ef7073eb1c446

cc @malfet @seemethere @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport
WARNING: The shape inference of prim::PadPacked type is missing, so it may result in wrong shape inference for the exported graph. Please consider adding it in symbolic function.
Labels: oncall: jit, onnx-triaged

### 🐛 Describe the bug

WARNING: The shape inference of prim::PadPacked type is missing, so it may result in wrong shape inference for the exported graph. Please consider adding it in symbolic function.

### Versions

CUDA 10.2
pytorch 1.10.1

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
gpu training  work well, but cpu training not work
Labels: module: cpu, triaged, module: fft

### 🐛 Describe the bug

model{
self.a=torch.nn.Parameter(torch.rand(10,10))
self.b=torch.nn.Parameter(torch.rand(10,10))
self.c=torch.nn.Parameter(torch.rand(1))
}
forward{
fft
ifft
...
}

i do model=model.cuda().cpu()
cpu training will work

### Versions

1.10
cuda 11.1

cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @mruberry @peterbell10
In torchelastic support running worker rank 0 on agent rank 0 consistently
Labels: oncall: distributed, triaged, module: elastic

### 🚀 The feature, motivation and pitch

Currently, when launching distributed jobs using torchrun, the Rank 0 worker can land on any arbitrary node. This ask is to add a new rendezvous implementation for which worker rank 0 always runs on agent rank 0.

### Additional context

This will improve observability of the distributed job by easily locating logs for the rank0 worker

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @dzhulgakov
`torch.ops.aten.empty` is not discoverable from `dir(torch.ops.aten)` until explicitly calling getattr
Labels: triaged, module: library

### 🐛 Describe the bug

Accidentally discovered this when I was trying to retrieve all `OpOverload`s under `torch.ops.aten`. I noticed that `torch.ops.aten.empty` (may or may not be the only case) is not discoverable from `for op in torch.ops.aten`. 

However, it does appear there is such an op since `torch.ops.aten.empty` returns a valid object. And after retrieving that through `getattr` explicitly, it appears under `dir(torch.ops.aten)`.

I wonder if this is a bug or by design? And if it's not a bug what's the recommended way to loop over all `torch.ops.aten`?

```python
>>> import torch
>>> "empty" in torch.ops.aten
False
>>> torch.ops.aten.empty
<OpOverloadPacket(op='aten.empty')>
>>> "empty" in torch.ops.aten
True
```

### Versions

Main from 5315317b7bbb13d1b8d91a682cec1fb4dace79e4

cc @anjali411
Conda MacOS installation install pytorch-1.13 rather than 2.0 as of Apr 4th
Labels: high priority, triage review, oncall: binaries, module: regression

### 🐛 Describe the bug

See https://hud.pytorch.org/hud/pytorch/builder/main/1?per_page=50&name_filter=cron%20%2F%20release%20%2F%20mac%20%2F%20conda-py3


Last successful run: https://github.com/pytorch/builder/actions/runs/4619355597/jobs/8168032918

First faulty run: https://github.com/pytorch/builder/actions/runs/4629742465/jobs/8190405098

### Versions

2.0

cc @ezyang @gchanan @zou3519 @seemethere
Ban GradScaler scale from being less than 1
Labels: triaged, module: amp (automated mixed precision)

### 🚀 The feature, motivation and pitch

We should standardize on a way to tell users when a reasonable/good scale for the AMP GradScaler cannot be found.

Context:

The grad scaler is awesome in that it "automatically" finetunes itself to settle on an ideal scale. However! There are instances where there is just no ideal scale for certain parameters, for example the one mentioned in issue #96755, where the scale becomes so so tiny that it causes infs and, consequently, nans. In this issue, we were nestled in the unlikely (but clearly not impossible) world where for a certain scale S, the scaled gradients were valid, but the unscaled (g/S) were invalid, leading to weird inconsistent behavior.

Generally, we want to be add invariants/guarantees to prevent weird inconsistent behavior and give users faster and clearer signal. Since the purpose of the scale is to scale UP the loss so that the grads do not underflow in fp16, we should set a hard boundary of scale must be greater than or equal to 1. Note that adding a check may induce a slight perf hit.

cc @mcarilli @ptrblck @leslie-fang-intel @jgong5 @ngimel @crcrpar @stas00 @albanD

### Alternatives

Do nothing, let users deal with nans from the perspective of BC + that there might be currently unimagined worlds where users want to handle nans themselves (?)

### Additional context

More context provided in https://github.com/pytorch/pytorch/issues/96755.
Torch hangs at import if tensorflow is imported first
Labels: oncall: binaries

### 🐛 Describe the bug

If I import tensorflow==2.12.0, and then try importing torch==2..0.0 , it hangs

Code to reproduce the error:
```
docker run --rm -it ubuntu:22.04
// once inside
apt-get update && apt-get install python3
apt-get install pip
pip install tensorflow==2.12.0 
pip install torch --extra-index-url https://download.pytorch.org/whl/cu118 
python3
import tensorflow
import torch
```
Note: the issue will persist even if you install torch-cpu, also on any Ubuntu:20.04 and above

### Versions

it says 404 not found, however, the version of torch is 2.0.0, same thing happens if it is torch-cpu

cc @seemethere @malfet
Parameterisation of MultivariateNormal distribution using Cholesky decomposition of precision matrix
Labels: module: distributions, feature, triaged

### 🚀 The feature, motivation and pitch

Currently, the `MultivariateNormal` distribution is parameterised based on the Cholesky factor of the covariance matrix, referred to in the code as `scale_tril` (I'm unsure where this naming comes from). While the distribution can be initialised with the full covariance or precision matrix instead, these are simply used to calculate `scale_tril` which is then used as the basis for all calculations, presumably for efficiency and numerical stability.

It is however possible to parameterise the distribution with Cholesky factor of the precision matrix. One possible implementation is laid out in [this report](https://arxiv.org/pdf/2003.05739.pdf) presented by a contributor to [FrEAI](https://github.com/vislearn/FrEIA), a PyTorch library for invertible NNs. The report argues a better numerical stability than traditional parameterisation, something which I have confirmed in my experiments (see “Additional context” section below).

I'm happy to work on this request myself. I have a working implementation of the `log_prob` and `sample` methods and am happy to work on expanding this to match the full `Distribution` interface and then integrating this into the existing implementation. One question would be whether this replaces the current functionality, or if this is activatable via a flag.

### Alternatives

A [PyTorch implementation of a GMM using this parameterisation](https://github.com/vislearn/FrEIA/blob/master/FrEIA/modules/gaussian_mixture.py) exists in [FrEAI](https://github.com/vislearn/FrEIA) but this is...
1. A full Gaussian mixture model, not a single multivariate distribution.
2. Built to be part of an invertible network, which makes the implementation difficult to use for non-invertible cases.

### Additional context

My use case is implementing a [Mixture Density Network](https://publications.aston.ac.uk/id/eprint/373/) to predict the parameters of a Gaussian Mixture Model for high-ish dimensional data (31 dimensions). I find the existing implementation of the `MultivariateNormal` distribution quickly runs into numerical stability issues and returns NaNs when calculating the log probabilities.

cc @fritzo @neerajprad @alicanb @nikitaved
CUPTI Initialization error 
Labels: module: cuda, triaged, oncall: profiler

### 🐛 Describe the bug

CUPTI error prevents CUDA profiling, even on Pytorch example code. 

Error message:
```
WARNING:2023-04-20 11:13:16 7278:7278 init.cpp:146] function cbapi->getCuptiStatus() failed with error CUPTI_ERROR_NOT_INITIALIZED (15)
WARNING:2023-04-20 11:13:16 7278:7278 init.cpp:147] CUPTI initialization failed - CUDA profiler activities will be missing
INFO:2023-04-20 11:13:16 7278:7278 init.cpp:149] If you see CUPTI_ERROR_INSUFFICIENT_PRIVILEGES, refer to https://developer.nvidia.com/nvidia-development-tools-solutions-err-nvgpuctrperm-cupti
```

Example code:
```
import torch
import numpy as np
from torch import nn
import torch.autograd.profiler as profiler


class MyModule(nn.Module):
    def __init__(self, in_features: int, out_features: int, bias: bool = True):
        super(MyModule, self).__init__()
        self.linear = nn.Linear(in_features, out_features, bias)

    def forward(self, input, mask):
        with profiler.record_function("LINEAR PASS"):
            out = self.linear(input)

        with profiler.record_function("MASK INDICES"):
            threshold = out.sum(axis=1).mean().item()
            hi_idx = np.argwhere(mask.cpu().numpy() > threshold)
            hi_idx = torch.from_numpy(hi_idx).cuda()

        return out, hi_idx
    

model = MyModule(500, 10).cuda()
input = torch.rand(128, 500).cuda()
mask = torch.rand((500, 500, 500), dtype=torch.float).cuda()

# warm-up
model(input, mask)

with profiler.profile(with_stack=True, profile_memory=True) as prof:
    out, idx = model(input, mask)

print(prof.key_averages(group_by_stack_n=5).table(sort_by='self_cpu_time_total', row_limit=5))

```

My system:
```
CUDA: 12.1
Driver: 5.30
Pytorch: 2.0
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2023 NVIDIA Corporation
Built on Mon_Apr__3_17:16:06_PDT_2023
Cuda compilation tools, release 12.1, V12.1.105
Build cuda_12.1.r12.1/compiler.32688072_0
```

I have checked that my CUDA installation works by running the `deviceQuery`and `bandwithTest` tests that are part of the cuda_samples library. I have also made sure the profiler is accesible by non-sudo code `RmProfilingAdminOnly: 0`


I have not added the collect_env.py output as I get a 404 not found error when trying to download?



### Versions

None

cc @ngimel @robieta @chaekit @aaronenyeshi @nbcsm @guotuofeng @guyang3532 @gaoteng-git @tiffzhaofb @dzhulgakov @davidberard98
add Half support for layer_norm on CPU
Labels: module: cpu, open source, module: half, ciflow/trunk, topic: not user facing, ciflow/mps

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #99590


### Testing
Single socket (icx, 32cores):
| shape | fp32 forward (ms) | fp16 forward (ms) | mixed fp32 fp16 forward (ms) | fp32 backward (ms) | fp16 backward (ms) | mixed fp32 fp16 backward (ms) |
| -- | -- | -- | -- | -- | -- | -- |
| (1, 8, 16) | 0.012 | 0.011 | 0.011 | 0.051 | 0.051 | 0.050 |
| (8 ,8, 16) | 0.013 | 0.013 | 0.013 | 0.054 | 0.053 | 0.051 |
| (32, 8, 16) | 0.015 | 0.014 | 0.014 | 0.059 | 0.054 | 0.052 |
| (64, 128, 56, 56) | 1.875 | 0.790 | 1.016 | 12.845 | 7.151 | 6.985 |
| (64, 128, 256, 256) | 50.226 | 25.462 | 35.736 | 328.957 | 179.615 | 175.618 |

Single core (icx):

| shape | fp32 forward (ms) | fp16 forward (ms) | mixed fp32 fp16 forward (ms) | fp32 backward (ms) | fp16 backward (ms) | mixed fp32 fp16 backward (ms) |
| -- | -- | -- | -- | -- | -- | -- |
| (1, 8, 16) | 0.012 | 0.011 | 0.011 | 0.040 | 0.041 | 0.041 |
| (8 ,8, 16) | 0.012 | 0.012 | 0.012 | 0.042 | 0.042 | 0.042 |
| (32, 8, 16) | 0.027 | 0.014 | 0.014 | 0.048 | 0.048 | 0.046 |
| (64, 128, 56, 56) | 58.054 | 11.034 | 17.928 | 108.603 | 48.816 | 50.244 |
| (64, 128, 256, 256) | 1327.758 | 352.394 | 496.994 | 2846.182 | 1224.247 | 1218.422 |


cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
Training Faster R-CNN model with COCO dataset has been consistently unsuccessful.
Labels: module: dataloader, triaged

### 📚 The doc issue

My computer has downloaded the COCO dataset and now I want to use PyTorch to load the dataset and train a Faster R-CNN object detection model. However, there seems to be a problem with loading the data. Can you help me solve this issue?The following is my code.

```python
import torchvision
import torch
import torchvision.transforms as transforms
from torch.utils.data import DataLoader
from torchvision.datasets import CocoDetection
from torchvision.models.detection import FasterRCNN
from torchvision.models.detection.rpn import AnchorGenerator
import torch.optim as optim
import torch.nn as nn
from torch.utils.tensorboard import SummaryWriter

## dataloader
transform = transforms.Compose([
    transforms.ToTensor(),
    transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225])
])

train_data_dir = '../data/coco/train2017'
train_ann_file = '../data/coco/annotations/instances_train2017.json'
val_data_dir = '../data/coco/val2017'
val_ann_file = '../data/coco/annotations/instances_val2017.json'

train_dataset = CocoDetection(root=train_data_dir, annFile=train_ann_file, transform=transform)
test_dataset = CocoDetection(root=val_data_dir, annFile=val_ann_file, transform=transform)
train_loader = DataLoader(train_dataset, batch_size=4, shuffle=True)
val_loader = DataLoader(test_dataset, batch_size=4, shuffle=False)

## model
backbone = torchvision.models.mobilenet_v2(pretrained=True).features
backbone.out_channels = 1280
anchor_generator = AnchorGenerator(sizes=((32, 64, 128, 256, 512),), aspect_ratios=((0.5, 1.0, 2.0),))
roi_pooler = torchvision.ops.MultiScaleRoIAlign(featmap_names=[0], output_size=7, sampling_ratio=2)
model = FasterRCNN(backbone, num_classes=80, rpn_anchor_generator=anchor_generator, box_roi_pool=roi_pooler)

## optimizeer and others
params = [p for p in model.parameters() if p.requires_grad]
optimizer = optim.SGD(params, lr=0.005, momentum=0.9, weight_decay=0.0005)
lr_scheduler = optim.lr_scheduler.StepLR(optimizer, step_size=3, gamma=0.1)
criterion = nn.SmoothL1Loss()

device = torch.device('cuda' if torch.cuda.is_available() else 'cpu')


## train model
model.train()
num_epochs = 10
for epoch in range(num_epochs):
    for i, (images, targets) in enumerate(train_loader):
        images = list(image.to(device) for image in images)
        targets = [{k: v.to(device) for k, v in t.items()} for t in targets]

        loss_dict = model(images, targets)
        losses = sum(loss for loss in loss_dict.values())

        optimizer.zero_grad()
        losses.backward()
        optimizer.step()

        if i % 100 == 0:
            print(f"Epoch [{epoch+1}/{num_epochs}], Step [{i+1}/{len(train_loader)}], Total Loss: {losses.item()}")
```

### Suggest a potential alternative/fix

_No response_

cc @SsnL @VitalyFedyunin @ejguan @NivekT @dzhulgakov
lintrunner mypy raises error in numpy
Labels: module: lint, triaged

On my machine, `lintrunner -a` produces the following output:
```
(/raid/rzou/pt/debug-cpu4-env) [0] rzou@devfair0317:/raid/rzou/pt/debug-cpu4 (debug-cpu4) $ lintrunner -a
  FLAKE8 success!
  CLANGFORMAT success!
  MYPY failure
  MYPYNOFOLLOW success!
  MYPYSTRICT success!
  CLANGTIDY success!
  TYPEIGNORE success!
  NOQA success!
  CIRCLECI success!
  NATIVEFUNCTIONS success!
  NEWLINE success!
  CONSTEXPR success!
  TABS success!
  INCLUDE success!
  SPACES success!
  ERROR_PRONE_ISINSTANCE success!
  PYBIND11_INCLUDE success!
  PYPIDEP success!
  PYBIND11_SPECIALIZATION success!
  EXEC success!
  RAWCUDA success!
  RAWCUDADEVICE success!
  ROOT_LOGGING success!
  CMAKE success!
  SHELLCHECK success!
  ACTIONLINT success!
  TESTOWNERS success!
  CALL_ONCE success!
  ONCE_FLAG success!
  WORKFLOWSYNC success!
  CUBINCLUDE success!
  UFMT success!
  COPYRIGHT success!
  BAZEL_LINTER success!
  LINTRUNNER_VERSION success!


>>> Lint for ../debug-cpu4-env/lib/python3.11/site-packages/numpy/__init__.pyi:

  Error (MYPY) [syntax]
    Positional-only parameters are only supported in Python 3.8 and greater

         633  |    def flush(self) -> object: ...
         634  |    def fileno(self) -> int: ...
         635  |    def tell(self) -> SupportsIndex: ...
    >>>  636  |    def seek(self, offset: int, whence: int, /) -> object: ...
         637  |
         638  |# NOTE: `seek`, `write` and `flush` are technically only required
         639  |# for `readwrite`/`write` modes

Successfully applied all patches.
```
the numpy error blocks any other errors from showing up.
Cross compile Pytorch for ARM in Bazel
Labels: module: build, triaged, enhancement, module: arm

### 🚀 The feature, motivation and pitch

My company has bazel as our build system, we have x86 and arm platforms in our environments. We have a cross compiling toolchain for ARM from x86. Because of this, we desire to have pytorch cross compile to ARM in bazel. 

We have a working prototype that we would like to upstream. 

We are filing this feature request to gauge community interest in bazel cross compile support for ARM in pytorch! 

Doc outlining a bit more: https://docs.google.com/document/d/1U4cUcfC_IYePL3LRfaqih21gB8I9L2Te_VUvaX9Yia4/edit#heading=h.y26v9c48rho1 

### Alternatives

_No response_

### Additional context

_No response_

cc @malfet @seemethere