gopikrsmscs/torch-issues huggingface dataset:
DISABLED test_inplace_grad_index_put_cuda_complex128 (__main__.TestBwdGradientsCUDA)
Labels: module: autograd, triaged, module: flaky-tests, skipped, oncall: pt2, module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_inplace_grad_index_put_cuda_complex128&suite=TestBwdGradientsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 3 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_inplace_grad_index_put_cuda_complex128`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_ops_gradients.py`

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @aakhundov
DISABLED test_inplace_grad_div_trunc_rounding_cuda_float64 (__main__.TestBwdGradientsCUDA)
Labels: module: autograd, triaged, module: flaky-tests, skipped, oncall: pt2, module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_inplace_grad_div_trunc_rounding_cuda_float64&suite=TestBwdGradientsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 3 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_inplace_grad_div_trunc_rounding_cuda_float64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_ops_gradients.py`

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @aakhundov
DISABLED test_fn_grad_div_trunc_rounding_cuda_float64 (__main__.TestBwdGradientsCUDA)
Labels: module: autograd, triaged, module: flaky-tests, skipped, oncall: pt2, module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_fn_grad_div_trunc_rounding_cuda_float64&suite=TestBwdGradientsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 6 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_fn_grad_div_trunc_rounding_cuda_float64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_ops_gradients.py`

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @aakhundov
Enable DEBUG asserts for C++ builds
Labels: triaged, module: devx

A continuation of https://github.com/pytorch/pytorch/issues/88842 to follow up on https://github.com/pytorch/pytorch/pull/92707

**Goal:** Ensure our debug builds actually trigger on C++ debug level asserts.

**Specific Asks**
1. Add a new environment variable (like DEBUG_ASSERT ) to debug builds, and make the debug asserts get run whenever that variable is set
2. Uncomment the code in test.sh added by https://github.com/pytorch/pytorch/pull/92707/files to verify that the debug mode is being respected.



cc @kit1980 @huydhn @clee2000
Documentation Error of torch.onnx
Labels: module: onnx, module: docs, triaged

### 📚 The doc issue

https://pytorch.org/docs/stable/onnx.html#limitations says that 
- Any output that is a dict will be silently replaced with a flattened sequence of its values (keys will be removed). E.g. {"foo": 1, "bar": 2} becomes (1, 2).

- Any output that is a str will be silently removed.

But I find that str actually triggers error:

```
import torch
from torch import nn

class MyModule(nn.Module):
    def __init__(self):
        super(MyModule, self).__init__()

    def forward(self, x, y_dict):
        y = y_dict['value']
        output = x + y
        return 'haha', {'output': output}


# Create the module
module = MyModule()

# Example usage
x = torch.tensor(2.0)
y = {'value': torch.tensor(3.0)}
string, output_dict = module(x, y)
print(string)  # Prints: haha
print(output_dict)  # Prints: {'output': tensor(5.)}
torch.jit.trace(module, (x,y)) # RuntimeError: Only tensors, lists, tuples of tensors, or dictionary of tensors can be output from traced functions
```

I'm using PyTorch 1.12.0.


### Suggest a potential alternative/fix

Remove those two sentences.

cc @svekars @carljparker
add Half support for AdaptiveAvgPool2d and AdaptiveMaxPool2d on CPU
Labels: module: cpu, open source, module: half, ciflow/trunk, ciflow/mps

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #102079

### Testing

Single core:

AdaptiveMaxPool2d:
shape | fp32 forward / ms | fp16 forward / ms | bf16 forward / ms | fp32 backward / ms | fp16 backward / ms | bf16 backward / ms
-- | -- | -- | -- | -- | -- | --
input size: (2, 56, 264, 264), output size: (100, 100)  | 71.5826 | 78.7460 | 85.7195 | 7.3925 | 6.0618 | 6.2596
input size: (2, 56, 264, 264), output size: (50, 50)  | 28.122 | 30.8572 | 36.6366 | 6.2645 | 3.4781 | 3.6628
input size: (32, 32, 100, 100), output size: (50, 50)  | 109.2978 | 115.0330 | 121.9500 | 13.4329 | 10.2769 | 12.1975
input size: (16, 4, 300, 300), output size: (100, 100) | 34.1849 | 36.5876 | 40.9862 | 4.7719 | 4.3362 | 4.1417


28 cores:

AdaptiveMaxPool2d:

shape | fp32 forward / ms | fp16 forward / ms | bf16 forward / ms | fp32 backward / ms | fp16 backward / ms | bf16 backward / ms
-- | -- | -- | -- | -- | -- | --
input size: (2, 56, 264, 264), output size: (100, 100)  | 3.1809 | 3.5057 | 3.6728 | 0.6657 | 0.3138 | 0.2934
input size: (2, 56, 264, 264), output size: (50, 50)  | 1.2779 | 1.3869 | 1.5238 | 0.4223 | 0.1775 | 0.1825
input size: (32, 32, 100, 100), output size: (50, 50)  | 4.7942 | 4.9670 | 5.2330 | 1.7146 | 0.6477 | 0.7001
input size: (16, 4, 300, 300), output size: (100, 100) | 1.9522 | 2.0879 | 2.3155 | 0.4370 | 0.3175 | 0.2828


cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
DISABLED test_build_tuple_unpack (__main__.DynamicShapesMiscTests)
Labels: triaged, module: flaky-tests, skipped, module: dynamo

Platforms: linux, mac, macos

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_build_tuple_unpack&suite=DynamicShapesMiscTests) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 3 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_build_tuple_unpack`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `dynamo/test_dynamic_shapes.py` or `dynamo/test_dynamic_shapes.py`

cc @voznesenskym @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx
Can't vmap over a slice expression
Labels: triaged, module: functorch

Code:
```
def foo(a, ind, len):
    ind2 = ind + len
    return a[ind:ind2]

torch.vmap(foo, in_dims=(0, 0, None))(a, c, 2)
```
RuntimeError: vmap: It looks like you're calling .item() on a Tensor. We don't support vmap over calling .item() on a Tensor, please try to rewrite what you're doing with other operations. If error is occurring somewhere inside PyTorch internals, please file a bug report.

cc @zou3519 @Chillee @samdow @kshitij12345 @janeyx99
[dynamo][BE] Revisit call_method of NNModuleVariable
Labels: triaged, oncall: pt2, module: dynamo

We have lots of specialization in NNModuleVariable `call_method` here - https://github.com/pytorch/pytorch/blob/main/torch/_dynamo/variables/nn_module.py#L468-L616

This task is to revisit this and cleanup. At the time of writing this code, there were large number of graph breaks and therefore we specialized for these methods. Today, it is possible that Dynamo can trace the innards of these methods and do the right thing!

Steps
* Take this commit -https://github.com/pytorch/pytorch/commit/f6c97b2b54b44f118c8b671ad982fde27b6f17ca
* Run `pytest test/dynamo/test_modules.py`. This is the start. 

cc @ezyang @msaroufim @wconstab @ngimel @bdhirsh @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx
DISABLED test_comprehensive_empty_strided_cuda_int64 (__main__.TestInductorOpInfoCUDA)
Labels: triaged, module: flaky-tests, skipped, module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_comprehensive_empty_strided_cuda_int64&suite=TestInductorOpInfoCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 2 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_comprehensive_empty_strided_cuda_int64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `inductor/test_torchinductor_opinfo.py` or `inductor/test_torchinductor_opinfo.py`

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10
DISABLED test_call_parent_non_class_methods_from_child (torch._dynamo.testing.DynamicShapesMiscTests)
Labels: triaged, module: flaky-tests, skipped, module: dynamo

Platforms: linux, mac

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_call_parent_non_class_methods_from_child&suite=DynamicShapesMiscTests) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 2 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_call_parent_non_class_methods_from_child`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `dynamo/test_dynamic_shapes.py` or `dynamo/test_dynamic_shapes.py`

cc @voznesenskym @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx
DISABLED test_comprehensive_empty_strided_cuda_float64 (__main__.TestInductorOpInfoCUDA)
Labels: triaged, module: flaky-tests, skipped, module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_comprehensive_empty_strided_cuda_float64&suite=TestInductorOpInfoCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 3 failures and 3 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_comprehensive_empty_strided_cuda_float64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `inductor/test_torchinductor_opinfo.py` or `inductor/test_torchinductor_opinfo.py`

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10
[FSDP] Ensure full precision checkpoints
Labels: oncall: distributed, triaged, module: fsdp

### 📚 The doc issue

The FSDP MixedPrecision API docs say that checkpoint in full precision is only ensured for full_state_dict, let's ensure we have support for sharded_state_dict and update.

### Suggest a potential alternative/fix

_No response_

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin
[FSDP] Summon buffers in full precision
Labels: oncall: distributed, module: fsdp

### 🐛 Describe the bug

We should check if we are doing this and fix as needed, and update the mixed precision API documentation.

### Versions

main

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
[PyTorch] Redirect c10::optional to std::optional
Labels: module: bc-breaking, module: cpu, NNC, release notes: quantization, release notes: distributed (c10d), topic: bc breaking

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #101995

We have C++17 now!

I am intentionally dropping the `c10::optional<c10::ArrayRef>` size optimization. It was intended to improve dispatch, but thanks to D34602980 / #70864 we don't use `optional<ArrayRef>` in function arguments anymore anyway.

Differential Revision: [D46079028](https://our.internmc.facebook.com/intern/diff/D46079028/)

cc @ezyang @gchanan @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @EikanWang
Request for adding support for `torch.rand_like`, `torch.randn_like`, `torch.randint_like` with `torch.Generator`
Labels: triaged, module: random

### 🚀 The feature, motivation and pitch

This issue proposes adding support for `torch.rand_like`, `torch.randn_like`, and `torch.randint_like` with the `torch.Generator` parameter in PyTorch.

**Motivation**
The motivation behind this proposal is to provide users with greater flexibility and control over random number generation when using these functions. Currently, the `torch.rand_like`, `torch.randn_like`, and `torch.randint_like` functions do not support the `torch.Generator` parameter, while their underlying functions, `torch.rand`, `torch.randn`, and `torch.randint`, already do. By adding support for the `torch.Generator` parameter to these functions, users can have consistent control over random number generation across different operations.

**Pitch**
I suggest updating the function signatures as follows:

```python
def rand_like(input, *, generator=None, ...):
    ...

def randn_like(input, *, generator=None, ...):
    ...

def randint_like(input, low, high=None, *, generator=None, ...):
    ...
```

The `generator` parameter would allow users to pass a `torch.Generator` object, with `None` as the default value. This would enable users to customize the random number generation process according to their specific requirements.

### Alternatives

_No response_

### Additional context

_No response_

cc @pbelevich
[feature request] [minor] Inplace torch.flip_
Labels: triaged, enhancement, module: python frontend

### 🚀 The feature, motivation and pitch

Some usecases: littleendian<>bigendian byte-swaps for various dtypes, BGR<>RGB

There currently is a specialized flip version in byteswap context, discussed in
https://github.com/pytorch/pytorch/pull/101925#issuecomment-1555883474, but it could be useful in other contexts too if integrated into torch.flip_. Also, in that issue is linked a nice article on vectorized array reversal which is useful for torch.flip over the inner-most dim on CPU: https://dev.to/wunk/fast-array-reversal-with-simd-j3p https://github.com/Wunkolo/qreverse

Seems mostly useful for very small inner-dim sizes: 2-8, but might also be useful for time series, if need to use some time-reversed representations

Another useful thing could be more general value shuffle (including inplace): along a dim, given a permutation (I think this shuffle op exists in SSE/AVX). Is it currently implemented by `index_select`? If so, an inplace version might be nice to have as well

### Alternatives

_No response_

### Additional context

_No response_

cc @albanD
can not find tensorrt
Labels: triaged, oncall: pt2

### 🐛 Describe the bug

I have tried below code.
 torch.compile(m, backend="tensorrt")
but can not found tensorrt in PyTorch 2.0.1

### Error logs

_No response_

### Minified repro

_No response_

### Versions

2.0.1

cc @ezyang @msaroufim @wconstab @ngimel @bdhirsh @anijain2305
torch.quantile on MPS doesn't sort values when dim is not None
Labels: high priority, triaged, module: correctness (silent), module: mps

### 🐛 Describe the bug

MPS implementation of `torch.quantile` doesn't sort the input when there's the `dim` argument is not `None`, giving nonsense results.

```
import torch
device = torch.device("mps")
A = torch.randn(1000, 10)

#need to use "nearest", "lower", or "higher" interpolation methods
#"linear" and "midpoint" fail due to operator `aten::lerp.Tensor_out` not being implemented for MPS
#when dim=None, CPU and MPS give same result
torch.quantile(A, .5, interpolation = "nearest")
torch.quantile(A.to(device), .5, interpolation = "nearest")

#when dim is not None, MPS gives nonsense result
torch.quantile(A, .5, 0, interpolation = "nearest")
torch.quantile(A.to(device), .5, 0, interpolation = "nearest")

#MPS output is same as middle row of tensor
#so torch.quantile must just be pulling 500th index without sorting first
A[500]

#inelegant workaround is to sort the tensor before calling quantile
torch.quantile(torch.sort(A.to(device), dim = 0).values, .5, 0, interpolation = "nearest")
```

### Versions

PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.3.1 (x86_64)
GCC version: Could not collect
Clang version: 14.0.6
CMake version: version 3.22.1
Libc version: N/A

Python version: 3.11.3 (main, Apr 19 2023, 18:51:09) [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M2 Pro

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] torch==2.0.1
[pip3] torchmetrics==0.11.4
[conda] nomkl                     3.0                           0  
[conda] numpy                     1.24.3          py311hd0e4f0d_0  
[conda] numpy-base                1.24.3          py311h947b413_0  
[conda] torch                     2.0.1                    pypi_0    pypi
[conda] torchmetrics              0.11.4                   pypi_0    pypi

cc @ezyang @gchanan @zou3519 @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
Can group convolution support other grouping methods?
Labels: module: convolution, triaged

### 🚀 The feature, motivation and pitch

I'm using group convolution, but I want to use a new grouping method. For example, I have a tensor called "a" with shape `[b, 256*3, h, w]`. I want to group `a[:, 0, :, :], a[:, 256, :, :], a[:, 256*2, :, :]` into one group, and `a[:, 1, :, :], a[:, 1+256, :, :], a[:, 1+256*2, :, :]` into another group, and so on, ultimately dividing it into 256 groups where each group is a tensor of shape `[b, 3, h, w]`. Then I want to perform group convolution with the number of groups set to 256. In other words, the grouping stride becomes 256. How can I achieve this? Can the nn.conv2D function handle this?
By the way, group convolution seems to be slower than regular convolution, which is contrary to theory. Is this due to optimization issues or is my torch version too low?

### Alternatives

_No response_

### Additional context

_No response_
Error, attribute exists on the Python module, but we failed to convert Python type: 'list' to a TorchScript type 
Labels: oncall: jit, module: onnx

### 🐛 Describe the bug

When I use **detectron2** TorchScript to export onnx,  the code use python list,  will report  error, This attribute exists on the Python module, but we failed to convert Python type: 'list' to a TorchScript type

```
RuntimeError: 
Module 'ResNet' has no attribute 'stages_and_names' (This attribute exists on the Python module, but we failed to convert Python type: 'list' to a TorchScript type.):
  File "/usr/local/lib/python3.7/dist-packages/detectron2/modeling/backbone/resnet.py", line 435
        if "stem" in self._out_features:
            outputs["stem"] = x
        for stage, name in self.stages_and_names:
                           ~~~~~~~~~~~~~~~~~~~~~ <--- HERE
            x = stage(x)
            if name in self._out_features:
```   

https://github.com/facebookresearch/detectron2/issues/2734  has the same error, it suggest to use torch1.8,  but not work for me. 

How to slove it ?   Thanks
 

### Versions

 ```
torch                         1.10.2+cu113     
detectron2                 0.6                   
```

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
torch.jit.trace() Floating point exception
Labels: oncall: jit

### 🐛 Describe the bug

When I user torch.jit.trace to turn an existing module into a TorchScript .The following exception occurred：
Floating point exception。
The code is as follows:
import torch 
example_input = torch.rand((1, 12, 255, 256)).float().cuda()
traced_model = torch.jit.trace(model_bpu.cpu(), example_input.cpu())

The model_bpu is a quant model after quantitative training. I loaded it from a  pt file and convert it to quant.


### Versions

torch                       1.10.2+cu111
torchaudio               0.10.2+cu111
torchvision              0.11.3+cu111
python                     3.8.1
Linux version 3.10.0-1160.49.1.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Tue Nov 30 15:51:32 UTC 2021



cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Update minimum supported gcc to gcc-9
Labels: module: build, triaged, enhancement, module: third_party, actionable

### 🚀 The feature, motivation and pitch

As this is the first compiler that has full support for C++17 features, for example https://en.cppreference.com/w/cpp/header/filesystem or [`std::exclusive_scan`](https://en.cppreference.com/w/cpp/algorithm/exclusive_scan) (for more info, see  https://godbolt.org/z/q19MPs1rP )

### Alternatives

Do not use C++17

cc @seemethere
[ATen][Sparse] Use Third-Party Eigen for sparse addmm
Labels: triaged, open source, ciflow/trunk, release notes: sparse

This pull request adds a functionality for addmm with the following layouts:
```python
    add(a_csr, b_csr)

    addmm(c_csr, a_csr, b_csr)
    addmm(c_csr, a_csr, b_csc)
    addmm(c_csr, a_csc, b_csc)
    addmm(c_csr, a_csc, b_csr)
```
using Eigen for non-MKL builds.

Edit: thanks to the comment https://github.com/pytorch/pytorch/pull/101814#discussion_r1210569201 the following ops were also added:
```python
    add(a_csc, b_csc)

    addmm(c_csc, a_csr, b_csr)
    addmm(c_csc, a_csr, b_csc)
    addmm(c_csc, a_csc, b_csc)
    addmm(c_csc, a_csc, b_csr)
```
Fix absolute links in pytorch repository and allow it to be proxied
Labels: oncall: releng, triaged

### 🐛 Describe the bug

The pip repositories like `https://download.pytorch.org/whl/cu118` do not follow common standards like PEP503.

While for itself pip this is not an issue, we are having trouble proxying the repository using Sonatype Nexus.

When looking at the actual location of the wheels, `https://download.pytorch.org/whl/torch/` the links to the wheel files use absolute paths like that:

`<a href="/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl">torch-2.0.1+cu117-cp310-cp310-linux_x86_64.whl</a>`

So far so good.

Now I am proxying the pytorch repo to make use of caching and faster downloads in our corporate network. Additionally direct internet access is not allowed. We are using a so-called "raw repository" inside Sonatype Nexus. We cannot use their "PyPI" repository feature, because the pytorch repository does not follow PEP503 standard. But that is a separate issue.

Our cached repository ends up at `https://nexus.corporate.info/repository/pytorch-raw/` with the wheels ending up at `https://nexus.corporate.info/repository/pytorch-raw/whl/torch/`. The page shows links the same way as the original repo.

`<a href="/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl">torch-2.0.1+cu117-cp310-cp310-linux_x86_64.whl</a>`

But a link like `/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl` ends up being resolved to `https://nexus.corporate.info/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl`

The correct URL should be `https://nexus.corporate.info/repository/pytorch-raw/whl/cu117/torch-2.0.1%2Bcu117-cp310-cp310-linux_x86_64.whl`

Could you please fix the absolute links and use relative ones if possible?

Alternatively, can you implement a PEP503 simple repository? What is the issue with that?



### Versions

2.0.1
Implement `to_numpy` method to speed up matplotlib with PyTorch arrays
Labels: triaged, enhancement, module: numpy, needs research

### 🚀 The feature, motivation and pitch

Hi,

As discussed in [this issue](https://github.com/matplotlib/matplotlib/issues/25882) and [corresponding PR](https://github.com/matplotlib/matplotlib/pull/25887) on `matplotlib`, PyTorch arrays can be significantly slow when used directly with `matplotlib`. This is because `matplotlib` has no easy way to convert PyTorch arrays to NumPy arrays before plotting and thus it expects other libraries to have `to_numpy()` method. I think `to_numpy()` implementation in PyTorch would be useful for the PyTorch users who might be using PyTorch arrays directly with `matplotlib` without knowing that it can be too slow.

### Alternatives

* As discussed in [the `matplotlib` PR](https://github.com/matplotlib/matplotlib/pull/25887), we considered adding a specific check for inputs of type `torch.Tensor` and then convert it to numpy using `.numpy()` method but adding a string based check does not seem a good idea.
* We tried using `__array__` method to convert both JAX and PyTorch arrays to NumPy but it does not work well with some other objects having `__array__` method.

### Additional context

Here is the code to reproduce the plotting delay issue:

```py
from time import time
import numpy as np
import matplotlib.pyplot as plt

import torch

torch_array = torch.randn(1000, 150)

def plot_hist(array):
    init = time()
    plt.figure()
    plt.hist(array)
    print(f"Time to plot: {time() - init:.2f} s")
    plt.show()

plot_hist(torch_array.ravel())  # Takes around 2 seconds
plot_hist(np.array(torch_array.ravel()))  # Takes around 0.04 seconds
```

I am open to a diverse set of suggestions to fix this issue.

cc @mruberry @rgommers
DISABLED test_decoder_padding_and_src_mask_bool_cpu (__main__.TestTransformersCPU)
Labels: module: nn, triaged, module: flaky-tests, skipped, oncall: transformer/mha

Platforms: dynamo

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_decoder_padding_and_src_mask_bool_cpu&suite=TestTransformersCPU) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 2 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_decoder_padding_and_src_mask_bool_cpu`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_transformers.py`

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @bhosmer @cpuhrsch @erichan1 @drisspg
DISABLED test_encoder_padding_and_src_mask_bool_cpu (__main__.TestTransformersCPU)
Labels: module: nn, triaged, module: flaky-tests, skipped

Platforms: dynamo

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_encoder_padding_and_src_mask_bool_cpu&suite=TestTransformersCPU) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 2 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_encoder_padding_and_src_mask_bool_cpu`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_transformers.py`

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Add support for bfloat16 in torch.from_numpy()
Labels: triaged, module: numpy, module: bfloat16

### 🚀 The feature, motivation and pitch

Currently, torch.from_numpy() doesn't support torch.bfloat16 data type. Adding this would allow users to copy bfloat16 numpy arrays back to Torch tensors.

### Alternatives

_No response_

### Additional context

_No response_

cc @mruberry @rgommers
DISABLED test_fn_grad_remainder_cuda_float64 (__main__.TestBwdGradientsCUDA)
Labels: triaged, module: flaky-tests, skipped, module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_fn_grad_remainder_cuda_float64&suite=TestBwdGradientsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 7 workflow(s) with 7 failures and 7 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_fn_grad_remainder_cuda_float64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_ops_gradients.py`

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
DISABLED test_fn_grad___rmod___cuda_float64 (__main__.TestBwdGradientsCUDA)
Labels: triaged, module: flaky-tests, skipped, module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_fn_grad___rmod___cuda_float64&suite=TestBwdGradientsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 7 workflow(s) with 14 failures and 7 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_fn_grad___rmod___cuda_float64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_ops_gradients.py`

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
DISABLED test_fn_gradgrad_remainder_cuda_float64 (__main__.TestBwdGradientsCUDA)
Labels: triaged, module: flaky-tests, skipped, module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_fn_gradgrad_remainder_cuda_float64&suite=TestBwdGradientsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 6 workflow(s) with 6 failures and 6 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_fn_gradgrad_remainder_cuda_float64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_ops_gradients.py`

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
DISABLED test_fn_grad_index_put_cuda_complex128 (__main__.TestBwdGradientsCUDA)
Labels: triaged, module: flaky-tests, skipped, module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_fn_grad_index_put_cuda_complex128&suite=TestBwdGradientsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/undefined).

Over the past 3 hours, it has been determined flaky in 11 workflow(s) with 22 failures and 11 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_fn_grad_index_put_cuda_complex128`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_ops_gradients.py`

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
[inductor][cpu] Cache for VecISA compilation results
Labels: triaged, open source, Stale, intel, module: inductor, ciflow/inductor, release notes: inductor

Fixes #100378

VecISA requires compiling a testing cpp program on every new process invocation, costing nearly 1 second on startup. Here we cache for VecISA compilation results and could directly read from cache next time if it exists.

cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @voznesenskym @penguinwu @EikanWang @Guobing-Chen @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @ngimel @desertfire
[refs] inplace references resize the input to match the broadcasted input shape
Labels: triaged, module: primTorch

### 🐛 Describe the bug

From a quick check,  the inplace references have incorrect behaviour when other arguments have higher rank than the input being inplaced into.

```python
import torch

torch.manual_seed(42)

def f(x, y):
    return x.add_(y)

x = torch.randn(3, 3)
y = torch.randn(3, 3, 3)

# output with shape [3, 3] doesn't match the broadcast shape [3, 3, 3]
# x.add_(y)

from torch._refs import add_

# Resizes `x` to the broadcasted shape of inputs
add_(x, y)
print(x.shape)  # [3, 3, 3]

```

Inplace references created with `_make_inplace` seem to have this problem.

Ref: https://github.com/pytorch/pytorch/blob/88b6a4577bad670c608424018caeba8698ad5f97/torch/_refs/__init__.py#L431

cc: @lezcano

### Versions

master

cc @ezyang @mruberry @ngimel @Lezcano @peterbell10
Unexpected behavior of fmod op in some float32 input
Labels: module: numerical-stability, triaged

### 🐛 Describe the bug

import torch
a = torch.tensor([0.84])
b = torch.tensor([0.02])

c = torch.fmod(a, b)

d = a - a.div(b, rounding_mode="trunc") * b
print(c)
print(d)



###
tensor([0.0200])
tensor([0.])
DISABLED test_compare_cpu__refs_empty_strided_cuda_float32 (__main__.TestCommonCUDA)
Labels: module: cuda, triaged, skipped

Platforms: rocm

This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/test_ops.py%3A%3ATestCommonCUDA%3A%3Atest_compare_cpu__refs_empty_strided_cuda_float32)).

cc @ngimel @jaglinux @arindamroy-eng
[Dynamo] Can't inline functions under torch.nn.parallel 
Labels: triaged, oncall: pt2, module: dynamo

### 🐛 Describe the bug

Actually for functions/modules under ```torch.nn```, we put a ```call_module``` in FX graph rather than inlining them.
https://github.com/pytorch/pytorch/blob/cb734123e2e1c533a72032fb63a6083f0eedb817/torch/_dynamo/variables/functions.py#L306-L320

This is because we assume modules under ```torch.nn``` are allowed modules, which is safely to be traced through AOT autograd. However, ```torch.nn.parallel``` is under this folder but with different semantics. I think we should have a better way to detect and distinguish them.

Quickly workaround to unblock:
```
--- a/torch/_dynamo/variables/functions.py
+++ b/torch/_dynamo/variables/functions.py
@@ -313,6 +313,7 @@ class UserMethodVariable(UserFunctionVariable):
             if (
                 module_attr is not None
                 and module_attr.startswith("torch.nn.")
+                and not module_attr.startswith("torch.nn.parallel")
                 or self.is_constant
             ):
                 return self.obj.call_method(
```



### Versions

N/A

cc @ezyang @msaroufim @wconstab @ngimel @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire
[BE]: pyupgrade Python to 3.8 - remove extraneous parentheses only
Labels: triaged, open source, Stale, release notes: mobile, release notes: quantization, ciflow/mps, module: inductor, module: dynamo, ciflow/inductor

This change removes all redundant/extraneous parentheses. It was done by running:

```bash
ruff check --target-version=py38 --select=UP034 --fix --verbose benchmarks/ caffe/ test/ tools/ torch/
```

I reviewed them all and they make sense to me.

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @desertfire @anijain2305
multiple values for argument `softmax_scale`
Labels: triaged, module: fsdp, oncall: pt2

### 🐛 Describe the bug

Posting this on behalf of Mosaic

```
pip install --no-cache-dir --find-links https://download.pytorch.org/whl/torch_stable.html torch==2.0.0+cu117 torchvision torchtext
pip install einops
```

`python attention.py`

https://raw.githubusercontent.com/sashaDoubov/llm-foundry/sasha/repro-issue/llmfoundry/models/layers/attention.py

### Error logs

Not an error but instead seeing this scary warning

```

[2023-05-15 23:04:35,681] torch._dynamo.symbolic_convert: [WARNING] /llm-foundry/llmfoundry/models/layers/attention.py <function xformers_attn_fn at 0x7f2a6834ed40> [UnspecializedNNModuleVariable(MultiheadAttention), TensorVariable(), TensorVariable(), TensorVariable(), ConstantVariable(int)] {'softmax_scale': ConstantVariable(float), 'attn_bias': TensorVariable(), 'key_padding_mask': ConstantVariable(NoneType), 'is_causal': ConstantVariable(bool), 'dropout_p': ConstantVariable(float), 'training': ConstantVariable(bool), 'needs_weights': ConstantVariable(bool)} multiple values for argument 'softmax_scale'

[2023-05-15 23:04:35,707] torch._dynamo.symbolic_convert: [WARNING] /llm-foundry/llmfoundry/models/layers/attention.py <function xformers_attn_fn at 0x7f2a6834ed40> [UnspecializedNNModuleVariable(MultiheadAttention), TensorVariable(), TensorVariable(), TensorVariable(), ConstantVariable(int)] {'softmax_scale': ConstantVariable(float), 'attn_bias': TensorVariable(), 'key_padding_mask': ConstantVariable(NoneType), 'is_causal': ConstantVariable(bool), 'dropout_p': ConstantVariable(float), 'training': ConstantVariable(bool), 'needs_weights': ConstantVariable(bool)} multiple values for argument 'softmax_scale'
```

## How to remove the error

As a workaround you can comment out softmax_scale and the code then works  https://gist.github.com/msaroufim/5fe1a5cf745e31baabeb62b8dce10c82 but that's not a real solution

### Versions

n

cc @zhaojuanmao @mrshenli @rohan-varma @awgu @ezyang @wconstab @ngimel @bdhirsh @anijain2305
Unable to do tensor comparison on Metal Performance Shaders (MPS)
Labels: triaged, module: mps

### 🐛 Describe the bug

Using the official [PyTorch example for MNIST](https://github.com/pytorch/examples/blob/main/mnist/main.py), 
I am unable to compute a[ tensor element-wise equality](https://pytorch.org/docs/stable/generated/torch.eq.html) on the [MPS backend](https://developer.apple.com/metal/pytorch/), supported by Apple Metal.
The problem happens in line 64, where the amount of correct predictions is computed: 

`correct += pred.eq(target.view_as(pred)).sum().item()`

So, the accuracy appears always to be 0, in line 68 to 70:

```
 print('\nTest set: Average loss: {:.4f}, Accuracy: {}/{} ({:.0f}%)\n'.format(
        test_loss, correct, len(test_loader.dataset),
        100. * correct / len(test_loader.dataset)))
```
That is, because the eq comparison evaluates everything to `False`. 

However, when I turn MPS off, by switching the `--no-mps` flag to True, I do obtain accuracies and the network trains as expected on CPU.

Why is that the case? Am I missing here something within my configuration or is this a bug?
I would really love to use the AMD GPU of my Intel-powered MacBook Pro.



### 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 13.3.1 (x86_64)
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.10.11 | packaged by conda-forge | (main, May 10 2023, 19:07:22) [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-13.3.1-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:
Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] torch==2.0.0
[pip3] torchaudio==2.0.0
[pip3] torchvision==0.15.1a0
[conda] mkl                       2022.2.1         h44ed08c_16952    conda-forge
[conda] numpy                     1.24.3          py310h7451ae0_0    conda-forge
[conda] pytorch                   2.0.0           cpu_py310h2bbf33f_0    conda-forge
[conda] torchaudio                2.0.0                 py310_cpu    pytorch
[conda] torchvision               0.15.1          cpu_py310hfdc6817_0    conda-forge

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
torch.cuda.set_device cannot use to set cpu device, but give an ambiguity hint
Labels: triaged

### 🐛 Describe the bug

when give the string parameter as input to set the device torch use，the hint shows that cpu is allow

``` python
import torch
torch.cuda.set_device("gpu:0") # it should be torch.cuda.set_device("cuda:0") but this is to get the hint
# RuntimeError: Expected one of cpu, cuda, ipu, xpu, mkldnn, opengl, opencl, ideep, hip, ve, fpga, ort, xla, lazy, vulkan, mps, meta, hpu, mtia, privateuseone device type at start of device string: gpu
``` 

but if I follow the hint, and try to use torch.cuda.set_device to set cpu as target device

``` python
import torch
torch.cuda.set_device("cpu")
#  ValueError: Expected a cuda device, but got: cpu
device = torch.device("cpu")
torch.cuda.set_device(device)
# ValueError: Expected a cuda device, but got: cpu
```

in neither way, the api won't allow me to do so, so the hint is pretty ambiguity.
I went to look at the torch.cuda.set_device source code and found
the torch.cuda.set_device use _get_device_index and the default parameter is 
``` python
def _get_device_index(device: Any, optional: bool = False,
                      allow_cpu: bool = False) -> int:
    ...
```
and actually won't allow the cpu set.
if `device = _get_device_index(device,allow_cpu = True)` is more reasonable in the `torch.cuda.set_device` call, considering the hint and user can use the function to set the global device as cpu.

### Versions

pytorch 2.1.0 and the latest version