gopikrsmscs/torch-issues huggingface dataset:
cpp_extension CUDA library path hard-coded as "lib64" but may be "lib"
Labels: module: cpp-extensions, triaged, actionable

### 🐛 Describe the bug

The path to libcudart.so is [hard-coded to be "lib64"](https://github.com/pytorch/pytorch/blob/71fe069d985e97b5947d133f2f2bde9adea01ed7/torch/utils/cpp_extension.py#L1691) when using the "load" and "load_inline" (Ninja) methods for C++ extensions. It may sometimes, however, instead be "lib". This is acknowledged in [the alternative setuptools installation method](https://github.com/pytorch/pytorch/blob/71fe069d985e97b5947d133f2f2bde9adea01ed7/torch/utils/cpp_extension.py#L1171). This will cause loading C++ extensions to fail for those whose libcudart.so is in "lib".

### Versions

N/A

cc @malfet @zou3519
[Quant] Validate FixedQParams observers in eager mode
Labels: oncall: quantization, triaged

Currently, in eager mode, we treat fixed qparams ops such as `torch.nn.Sigmoid` and `torch.nn.Tanh` as having "special activation post process" according to this mapping:
https://github.com/pytorch/pytorch/blob/a16ced03c93dcbc5b08d0f9a36f8feab583f129a/torch/ao/quantization/quantization_mappings.py#L188-L193

Even if the user explicitly configured a QConfig for these modules, we would overwrite the configured observers with a `FixedQParamsFakeQuantize`. https://github.com/pytorch/pytorch/pull/88498 recently added a workaround for users to override this behavior, but requires users to explicitly specify these modules in `non_leaf_module_list`.

Instead, what we should do is don't overwrite the observers set by the users, but instead validate whether these observers satisfy our requirements. We did this recently with FX graph mode quantization already (https://github.com/pytorch/pytorch/pull/80184) and we should do the same for eager mode.

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
Dynamo handling for all methods of torch.Generator
Labels: triaged, module: dynamo

### 🐛 Describe the bug

We have a few different conditionals (https://github.com/pytorch/pytorch/blob/7076a6481d9f6d3ed40af1eac285fe5046a87531/torch/_dynamo/variables/torch.py#L294-L313, https://github.com/pytorch/pytorch/blob/7076a6481d9f6d3ed40af1eac285fe5046a87531/torch/_dynamo/variables/torch.py#L314-L337, https://github.com/pytorch/pytorch/blob/7076a6481d9f6d3ed40af1eac285fe5046a87531/torch/_dynamo/variables/tensor.py#L233-L241) to handle methods on torch.Generator and some torch.random functions, but it doesn't cover every function and method, for e.g., https://pytorch.org/docs/stable/generated/torch.Generator.html?highlight=manual_seed#torch.Generator.manual_seed. Creating this issue for a general strategy as well as figure out how to add support for `Generator.manual_seed`



### Versions

master

cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire
Add support for `torch.Generator` in the FX IR
Labels: oncall: fx

### 🐛 Describe the bug

Code samples that don't work:
```
def fn1(x):
    return torch.manual_seed(x)
    
def fn2(x):
    g_cpu = torch.Generator()
    return g_cpu.manual_seed(x)
```
```
b = make_fx(fn1)
# b = make_fx(fn2)
b(1729).print_readable()
```

```
incomplete graph:
class fn1(torch.nn.Module):
    def forward(self, x_1):
        pass

Traceback (most recent call last):
  File "/scratch/chourdiaanjali/work/pytorch/tryy2.py", line 22, in <module>
    b(1729).print_readable()
  File "/scratch/chourdiaanjali/work/pytorch/torch/fx/experimental/proxy_tensor.py", line 665, in wrapped
    t = dispatch_trace(wrap_key(func, args, fx_tracer), tracer=fx_tracer, concrete_args=tuple(phs))
  File "/scratch/chourdiaanjali/work/pytorch/torch/fx/experimental/proxy_tensor.py", line 422, in dispatch_trace
    graph = tracer.trace(root, concrete_args)
  File "/scratch/chourdiaanjali/work/pytorch/torch/fx/_symbolic_trace.py", line 739, in trace
    (self.create_arg(fn(*args)),),
  File "/scratch/chourdiaanjali/work/pytorch/torch/fx/experimental/proxy_tensor.py", line 412, in create_arg
    return super().create_arg(a)
  File "/scratch/chourdiaanjali/work/pytorch/torch/fx/_symbolic_trace.py", line 344, in create_arg
    return super().create_arg(a)
  File "/scratch/chourdiaanjali/work/pytorch/torch/fx/proxy.py", line 165, in create_arg
    raise NotImplementedError(f"argument of type: {type(a)}")
NotImplementedError: argument of type: <class 'torch._C.Generator'>
```

### Versions

master

cc @ezyang @SherlockNoMad @EikanWang @jgong5 @wenzhe-nrv
What causes CPU to degrade when I load the weight with torch.hub.load()
Labels: module: cpu, triaged, module: hub, intel

### 🐛 Describe the bug

## My problem
Hi @pytorchbot 

I use detect.py file to detect object then CPU: 78.1%.
On the other hand, I  load weight by **_torch.hub.load()_** then CPU: 16,2%. 
- torch.hub.load()
![Screenshot from 2022-11-04 15-43-55](https://user-images.githubusercontent.com/83366198/199931602-25dbd47d-26c3-44f1-aeef-1fe65100d775.png)

- run detect.py
 
![Screenshot from 2022-11-04 15-51-50](https://user-images.githubusercontent.com/83366198/199932821-5232721a-f356-4aba-aef8-4b15093f3fd6.png)

Can you point out what the cause is?

### Versions

i load weight by **torch.hub.load()** such as in line 10: https://github.com/TRINHHOANGANH/test_yolov5_torch_hub.git
![image](https://user-images.githubusercontent.com/83366198/200096005-faca8e3d-30e2-4c5b-bb98-f04609b6c8c6.png)

cc @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @nairbv @NicolasHug @vmoens @jdsgomes
We probably are allowing mutations to happen on fake tensor in VariableTracker
Labels: triaged, bug, module: dynamo

### 🐛 Describe the bug

VariableTracker is supposed to be immutable, so we can do checkpointing and rollback when instruction translation fails and we need to create a graph break.

However, we (indirectly) store fake tensor in VariableTracker, and fake tensor is not treated immutably. In particular, when we run nodes on fake tensor, those nodes may modify the metadata of the input fake tensor, and I don't see any logic that appropriately duplicates fake tensors so that we can safely run modifications on them.

The hypothetical bug is that we checkpoint, we then run the symbolic evaluator on `squeeze_`, and that mutates the fake tensor, but then we discover we need to rollback, and now subsequent code will see incorrect metadata for the input to squeeze. Discussing this with jansel, this is unlikely to happen in practice today, because the only time we rollback is right before we are generating a graph break, and at that point we're not going to actually insert any more nodes into the graph. But it will be good to get this correct, in case we end up using checkpointing more seriously in the future. More generally, we probably need some sort of lint to make sure that VariableTrackers do not actually get mutated, because they're not going to turn into real bugs immediately if you corrupt the state.

cc @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire @eellison @jansel 

### Error logs

_No response_

### Minified repro

_No response_
Don't store example_value on FX node meta
Labels: triaged, bug

### 🐛 Describe the bug

Storing it in the meta dict implies that we will pass it to the backend compiler. But actually we strip all of the example values from the FX graph when we're done. So this is really just an internal concept to Dynamo. I propose we store it on TensorVariable instead.

BTW, you don't want to actually pass this metadata on to the backend, because in the presence of metadata mutation it can be misleading. E.g.:

```
@torch._dynamo.optimize(my_backend)
def f(x):
    y = x.clone()
    y.transpose_(0, 1)
    return y

f(torch.randn(4, 5))
```

What do you expect the example value of y to be?

cc @eellison @Chillee @voznesenskym @jansel 

### Error logs

_No response_

### Minified repro

_No response_
DISABLED test_module_attribute_mutation_violation_negative_2 (__main__.MutationExportTests)
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_module_attribute_mutation_violation_negative_2&suite=MutationExportTests) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/9284427989).

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 BE ALARMED 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_module_attribute_mutation_violation_negative_2`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx
Mixed precision training fails due to NaN in batch norm running_mean
Labels: triaged, module: amp (automated mixed precision)

### 🐛 Describe the bug

During mixed precision training, the NaN gradient is skipped by grad_scaler. However, the NaN output will destroy the batch norm running mean and variance. This is severe because:
1. It can only be observed during validation since during training the running_mean and running_variance are not used.
2. It will break the whole training process of AMP.

Can batch norm skip NaN samples while updating the running_mean and running_var? Is there any way to achieve such a purpose? Following is an MRE. 
```python
import torch 
data = torch.rand(2, 3, 10).cuda()
from torch import nn
from torch.cuda.amp import autocast as autocast

network = nn.Sequential(
    nn.Conv1d(3, 16, 3, padding=1),
    nn.ReLU(),
    nn.BatchNorm1d(16)).cuda()

with autocast():
    data = data.half() * 100000
    output = network[0](data)
    output = network[1](output)
    output = network[2](output)
    print(network[1].running_mean)
```
The output is :
```
tensor([nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan],
       device='cuda:0')
```

### Versions

PyTorch version: 1.10.1
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.3 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.102.1-microsoft-standard-WSL2-x86_64-with-glibc2.31

cc @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @mcarilli @ptrblck @leslie-fang-intel
DISABLED test_module_attribute_mutation_violation_negative_1 (__main__.MutationExportTests)
Labels: triaged, module: flaky-tests, skipped, module: dynamo

Platforms: linux, macos, mac

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_module_attribute_mutation_violation_negative_1&suite=MutationExportTests) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/9284368349).

Over the past 3 hours, it has been determined flaky in 4 workflow(s) with 7 failures and 4 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT BE ALARMED 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_module_attribute_mutation_violation_negative_1`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx
DISABLED test_module_attribute_mutation_violation_negative_4 (__main__.MutationExportTests)
Labels: triaged, module: flaky-tests, skipped, module: dynamo

Platforms: linux, macos

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_module_attribute_mutation_violation_negative_4&suite=MutationExportTests) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/9279095156).

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 BE ALARMED 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_module_attribute_mutation_violation_negative_4`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx
DISABLED test_module_attribute_mutation_violation_negative_3 (__main__.MutationExportTests)
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_module_attribute_mutation_violation_negative_3&suite=MutationExportTests) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/9284454926).

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

**Debugging instructions (after clicking on the recent samples link):**
DO NOT BE ALARMED 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_module_attribute_mutation_violation_negative_3`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx
MaxPool1D output shapes can be negative when ceil_mode=True
Labels: module: nn, triaged, module: pooling

### 🐛 Describe the bug

When ceil_mode=True, output shape can potentially be negative, which is nonsensical. I think the calcuation of output shape for that case is wrong.

This seems related to issue https://github.com/pytorch/pytorch/issues/88144

```python
import torch

m = torch.nn.MaxPool1d(kernel_size=4, stride=1, padding=0, dilation=1, ceil_mode=True)
input = torch.randn(20, 16, 1)
output = m(input)
```

```
Traceback (most recent call last):
  File "/Users/mitch/***/avgpool.py", line 6, in <module>
    output = m(input)
  File "/opt/homebrew/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/torch/nn/modules/pooling.py", line 92, in forward
    return F.max_pool1d(input, self.kernel_size, self.stride,
  File "/opt/homebrew/lib/python3.10/site-packages/torch/_jit_internal.py", line 485, in fn
    return if_false(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/torch/nn/functional.py", line 696, in _max_pool1d
    return torch.max_pool1d(input, kernel_size, stride, padding, dilation, ceil_mode)
RuntimeError: max_pool1d() Invalid computed output size: -2
```

My experiments suggest that output shape for ceil_mode = True should be `ceiling((inputsize + padleft) / stride)`.


### Versions

```
Collecting environment information...
PyTorch version: 1.13.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.5 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.102)
CMake version: version 3.24.2
Libc version: N/A

Python version: 3.10.6 (main, Aug 30 2022, 04:58:14) [Clang 13.1.6 (clang-1316.0.21.2.5)] (64-bit runtime)
Python platform: macOS-12.5-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.3
[pip3] torch==1.13.0
[pip3] torchaudio==0.13.0
[pip3] torchvision==0.14.0
[conda] Could not collect
```

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
`unique` will reverse the input when `sort=False` on cpu (not sorting)
Labels: module: cpu, triaged, intel

### 🐛 Describe the bug

`unique` will reverse the input when sort=False on cpu (not sorting). By contrast, the cuda will keep the order.

```py
import torch

input = torch.FloatTensor([1, 3])
torch.unique(input, sorted=False)
# tensor([3., 1.])
torch.unique(input.cuda(), sorted=False)
# tensor([1., 3.], device='cuda:0')
```

You can see the input is in the ascending order. Even `sort=True` it should return the `[1, 3]`. But cpu will reverse the input to a descending order

### Versions

torch: 1.13.0
cuda: 11.6

cc @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
torch._dynamo.exc.Unsupported: call_function UserDefinedClassVariable() [] {} ([Feature request] Allow custom classes with custom __setattr__ method in torchdynamo)
Labels: high priority, triage review, triaged, enhancement, oncall: pt2

### 🐛 Describe the bug

Currently following doesn't work:
```
class Instances:
    def __init__(self, image_size: Tuple[int, int]):
        self._image_size = image_size

    def __setattr__(self, name: str, val) -> None:
        super().__setattr__(name, val)

def f(x):
    a = Instances((4, 5))
    return x


gm, _ = torchdynamo.export(f, torch.ones((4, 5)))

# Error 
torch._dynamo.exc.Unsupported: call_function UserDefinedClassVariable() [ConstantVariable(tuple)] {}
```
This is because torchdynamo doesn't allow custom setattr in user provided class. @jansel mentioned it might be doable if the custom setattr doesn't have graph breaks. 

### Error logs

_No response_

### Minified repro

_No response_

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @wconstab @bdhirsh @anijain2305 @soumith @ngimel
Hang: sampling VonMises distribution gets stuck in rejection sampling for small kappa
Labels: high priority, module: distributions, module: cpu, triaged, module: numpy, module: deadlock

### 🐛 Describe the bug

Sampling the VonMises distribution gets stuck in rejection sampling for small values of the concentration parameter. With the location parameter set to 1, the problem starts around ~1e-4 for single and ~1e-8 for double precision.

```torch.distributions.von_mises.VonMises(torch.Tensor([1]), torch.Tensor([1e-4])).sample()```

Numpy doesn't have this problem, likely because small values of the concentration are caught and handled explicitly, see [here](https://github.com/numpy/numpy/blob/623bc1fae1d47df24e7f1e29321d0c0ba2771ce0/numpy/random/src/legacy/legacy-distributions.c#L421). Implementing this might solve the issue.

### Versions

Collecting environment information...
PyTorch version: 1.12.1
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (conda-forge gcc 12.1.0-17) 12.1.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.35

Python version: 3.8.13 (default, Oct 21 2022, 23:50:54)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-52-generic-x86_64-with-glibc2.17
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: 
GPU models and configuration: GPU 0: NVIDIA T600 Laptop GPU
Nvidia driver version: 515.76
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.5
[pip3] torch==1.12.1
[pip3] torchaudio==0.12.1
[pip3] torchvision==0.13.1
[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-service               2.4.0            py38h7f8727e_0  
[conda] mkl_fft                   1.3.1            py38hd3c417c_0  
[conda] mkl_random                1.2.2            py38h51133e4_0  
[conda] numpy                     1.21.5           py38h6c91a56_3  
[conda] numpy-base                1.21.5           py38ha15fc14_3  
[conda] pytorch                   1.12.1          py3.8_cuda10.2_cudnn7.6.5_0    pytorch
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] torchaudio                0.12.1               py38_cu102    pytorch
[conda] torchvision               0.13.1               py38_cu102    pytorch

cc @ezyang @gchanan @zou3519 @fritzo @neerajprad @alicanb @nikitaved @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @mruberry @rgommers
Enable AMP for MPS devices
Labels: feature, triaged, module: amp (automated mixed precision), module: mps

### 🚀 The feature, motivation and pitch

https://github.com/pytorch/pytorch/issues/78168 States that fp16 support for mps devices in general should be possible, but autocas only works with `cpu` and `cuda` device types. When enabling it manually, on mps it does not show any additional conversions:

```python
>>> torch.set_autocast_enabled(True)
>>> with capture_logs(is_mode=True) as logs, LoggingTensorMode():
...     a = torch.rand(10, 10, dtype=torch.float, device='mps')
...     b = torch.rand(10, 10, dtype=torch.float, device='mps')
...     c = torch.addmm(a, a, b)
>>> for l in logs:
...     print(l)
```

prints the following:
```
$0 = torch._ops.aten.rand.default([10, 10], dtype=torch.float32, device=device(type='mps'), pin_memory=False)
$1 = torch._ops.aten.rand.default([10, 10], dtype=torch.float32, device=device(type='mps'), pin_memory=False)
$2 = torch._ops.aten.addmm.default($0, $0, $1)
```

given the fp16 support, it would be nice to have autocast and amp in general working on MPS devices as well

### Alternatives

_No response_

### Additional context

cc @mcarilli @ptrblck @leslie-fang-intel @jgong5 @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev as per our discussion on slack.
Flaky dynamo test_indexing flaky with SIGKILL
Labels: module: ci, triaged, module: dynamo

### 🐛 Describe the bug

This job starts to be flaky with SIGKILL recently:

* https://hud.pytorch.org/hud/pytorch/pytorch/master/1?per_page=50&name_filter=dynamo
* https://hud.pytorch.org/pytorch/pytorch/commit/b013825c7d104dca2c6c11cd985453d8520577f7

### Versions

Dynamo, linux-bionic-py3.7-clang9

cc @seemethere @malfet @pytorch/pytorch-dev-infra @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire @ezyang @gchanan @zou3519
benchmark cache persist
Labels: module: cudnn, module: cuda, triaged

## 🚀 The feature, motivation and pitch
### Background
We've been working on a detection model's training and when setting   torch.backends.cudnn.benchmark = True with some padding , the training speed can improve a lot .  However if we skip the padding, since the params of convolution vary frequently(e.g. input shapes), it  becomes even slower. 

### Requests
We are wondering if we can  persist the benchmark cache, so that the first person can store some cache and later others will no longer have to suffer from the algorithms choosing overhead.

Will this feature be possible in the future or is already ongoing ? 
**Or there are limits that this whole persisting thing is not a good idea**.



## Alternatives

For example, maybe we can define load() and save() functions inside the global variables:
```
BenchmarkCache<cudnnConvolutionFwdAlgoPerf_t> fwd_algos;
BenchmarkCache<cudnnConvolutionBwdDataAlgoPerf_t> bwd_data_algos;
BenchmarkCache<cudnnConvolutionBwdFilterAlgoPerf_t> bwd_filter_algos;
``` 
then we have to determine the time of load and save are executed, a draft would be like this:
```
template <typename T>
struct BenchmarkCache {
  std::mutex mutex;
  std::unordered_map<ConvolutionParams, T, ParamsHash<ConvolutionParams>, ParamsEqual<ConvolutionParams>> map;
  std::string CACHE_STORED_PATH;
  BenchmarkCache(std::string cache_stored_path): CACHE_STORED_PATH(cache_stored_path){}

  bool find(const ConvolutionParams& params, T* results) {
    std::lock_guard<std::mutex> guard(mutex);
    auto it = map.find(params);
    if (it == map.end()) {
      return false;
    }
    *results = it->second;
    return true;
  }

  void insert(const ConvolutionParams& params, const T& results) {
    std::lock_guard<std::mutex> guard(mutex);
    map[params] = results;
  }

  int load(const &std::string CACHE_STORE_PATH){
    std::lock_guard<std::mutex> guard(mutex);
    //load the cache;
  }

  int save(const &std::string CACHE_STORE_PATH){
    std::lock_guard<std::mutex> guard(mutex);
    //save the cache;
  }
};
```

### Additional context

_No response_

cc @csarofeen @ptrblck @xwang233 @ngimel
Unit test with `--subprocess` command doesn't respect the `-k` filter flag and runs all available sub tests
Labels: module: ci, module: tests, triaged, module: testing

### 🐛 Describe the bug

Unit test with `--subprocess` command doesn't respect the `-k` filter flag and runs all available sub tests

Example
```python
root@e85f1ff8919d:/opt/pytorch/pytorch# python test/test_nn.py -v -k test_add_relu
test_add_relu (__main__.TestAddRelu) ... ok
test_add_relu_broadcasting (__main__.TestAddRelu) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.002s

OK
```

However
```
root@e85f1ff8919d:/opt/pytorch/pytorch# python test/test_nn.py -v -k test_add_relu --subprocess

# thousands of lines of output are printed
# all tests in test_nn are executed
```

Distributed tests are executed by default with `--subprocess`, which makes it hard to only test a specific sub test. https://github.com/pytorch/pytorch/blob/a8f40b39ce4f9fa9ffd90400b7d10ea4051d623a/test/run_test.py#L634-L635

Something here might need to be changed? https://github.com/pytorch/pytorch/blob/a8f40b39ce4f9fa9ffd90400b7d10ea4051d623a/torch/testing/_internal/common_utils.py#L691-L693

### Versions

pytorch: https://github.com/pytorch/pytorch/commit/ccf6b558a4c58d1ae92689b2a5064916b42eff05

cc @seemethere @malfet @pytorch/pytorch-dev-infra @mruberry @ptrblck @ngimel
Whether to support libtorch source code compilation of C++11 ？
Labels: module: build, triaged

### 🐛 Describe the bug

Hello! 
I want to use libtorch's c++ api for algorithm inference, but currently the c++ version in my project only supports c++11, corresponding to gcc 4.8.5 and g++ 4.8.5, can I compile it by downloading the source code to support c++ Algorithm running under 11 environment?

### Versions

gcc 4.8.5
g++ 4.8.5
CUDA 11.3
CUDNN 8.2.1


cc @malfet @seemethere
Summary of inductor issues observed on master
Labels: high priority, module: ci, triaged, module: inductor

### 🐛 Describe the bug

As we have had inductor tests running in master for a while, here are the list of flaky issues that we have observed on master.  The CUDA GPU flakiness https://github.com/pytorch/pytorch/issues/88352 is not included here because it's related to AWS G5 runner in general, not inductor workflow.

* Fail to build triton wheel
  * https://hud.pytorch.org/pytorch/pytorch/commit/bc03aa6013e101222c9652d04a2b08e48f626dfb
* benchmarks/dynamo/timm_models.py failure with KeyError: 'cubin'
  * https://hud.pytorch.org/pytorch/pytorch/commit/8ef9bda1bf7df84483c593f55e704657887120d6
* benchmarks/dynamo/timm_models.py timeout
  * https://hud.pytorch.org/pytorch/pytorch/commit/0fc7de398636f4b53e6c3fde38b4e48a5ff5b37d
  * https://hud.pytorch.org/pytorch/pytorch/commit/f132c171ac542c8abe8f6bf54befd9f2e14ad9b6
  * https://hud.pytorch.org/pytorch/pytorch/commit/1e2c4a6e0e60dda763b53f00f25ee5c1f1e5233d
* fbnetc_100 model fails
  * https://hud.pytorch.org/pytorch/pytorch/commit/5b75b19f51837e162cc0e5e5757dfd9bef437c67   
* Internal Triton PTX codegen error
  * https://hud.pytorch.org/pytorch/pytorch/commit/7354368fd5a8dec5c9fc26dddf5f7da37f1d2499 
  * https://hud.pytorch.org/pytorch/pytorch/commit/12dd877395a47d4de382b06fda9623da37782226 

Let's try to address them to keep master green

### Versions

Inductor, A10G G5 runner, sm86

cc @ezyang @gchanan @zou3519 @seemethere @malfet @pytorch/pytorch-dev-infra @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire
Move Dropout to LowMemDropout Replacement To PyDispatcher
Labels: triaged, oncall: pt2

Dynamo tracing will replace [dropout](https://github.com/pytorch/pytorch/blob/master/torch/_inductor/overrides.py#L295) with [LowMemDropout](https://github.com/pytorch/pytorch/blob/master/torch/_inductor/overrides.py#L247). Because we are doing it at the bytecode level, this replacment is fragile, and does not work for `nn.Dropout`. We should instead use a pre-autograd pydispatcher decomposition to do the replacement. We should also do this for the `rand_like` replacement.

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
MSE documentation is weak
Labels: module: docs, triaged

### 📚 The doc issue

Currently we have the MSE described as following:

> `CLASS` `torch.nn.MSELoss`(`size_average=None`, `reduce=None`, `reduction='mean'`)[[SOURCE]](https://pytorch.org/docs/stable/_modules/torch/nn/modules/loss.html#MSELoss)
Creates a criterion that measures the mean squared error (squared L2 norm) between each element in the input $x$ and target $y$.
> 
> The unreduced (i.e. with `reduction` set to `'none'`) loss can be described as:
>
> $$
> \ell(x, y) = L = \lbrace l_1,\dots,l_N\rbrace^\top, \quad l_n = \left( x_n - y_n \right)^2,
> $$

Which is not the case.
Say `x` and `y` have `N = 3` elements, `L` does **not** contain the `N` squared L2 norms.

```python
>>> # Define cost
>>> C = nn.MSELoss(reduction='none')
>>> x = torch.randn(3, 5)
>>> y = torch.randn(3, 5)
>>> C(x, y).size()
torch.Size([3, 5])
```

We're assuming the first dimension is the batch size, yes?

cc @svekars @carljparker
Group losses in a common namespace
Labels: module: nn, module: loss, triaged, needs research

### 🚀 The feature, motivation and pitch

It would be nice to remove the need to go fish losses from the `nn` module and have them all in a common `nn.loss` namespace.

So, instead of having
```
nn.L1Loss
nn.MSELoss
nn.CrossEntropyLoss
nn.CTCLoss
nn.NLLLoss
```
we would have
```
nn.loss.L1
nn.loss.MSE
nn.loss.CrossEntropy
nn.loss.CTC
nn.loss.NLL
```

Such a hierarchy (Containers, Convolution Layers, Pooling layers, Padding Layers, *etc*…) already exists in the [`nn` documentation](https://pytorch.org/docs/stable/nn.html) and, IMHO, should be reflected in the API as well. Is there a reason why this is not the case?

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
ASAN shard 4 started to OOM after unrelated commit
Labels: module: ci, triaged

### 🐛 Describe the bug

See https://hud.pytorch.org/hud/pytorch/pytorch/master/1?per_page=50&name_filter=asan%20%2F%20test%20(default%2C%204%2C%205


Error looks as follows:
```
test_serialization_offset_filelike_weights_only_False (__main__.TestOldSerialization) ... =================================================================
==1033==ERROR: AddressSanitizer: allocator is out of memory trying to allocate 0x80000000 bytes
```

First commit (clearly unrelated): https://hud.pytorch.org/pytorch/pytorch/commit/a51da28551e9f13a7afca5bbc829a8d9abced44e

### Versions

CI

cc @ezyang @gchanan @zou3519 @seemethere @pytorch/pytorch-dev-infra
AttributeError: module 'tensorboard.compat.tensorflow_stub.io.gfile' has no attribute 'MakeDirs'
Labels: triaged, module: tensorboard

### 🐛 I am trying to run this code of BERT-based calssification, but I got this error message, where it says that there is no attribute in the tensorboard. Below is the imported line and the error line is given where the code threw the error. 

Is it because of the version that I am using: 

> tensorboard               2.10.1                   pypi_0    pypi
> tensorboard-data-server   0.6.1                    pypi_0    pypi
> tensorboard-plugin-wit    1.8.1                    pypi_0    pypi
> tensorflow                1.15.0          mkl_py37h28c19af_0  
> tensorflow-base           1.15.0          mkl_py37he1670d9_0  
> tensorflow-estimator      1.15.1             pyh2649769_0  
> tensorflow-hub            0.12.0                   pypi_0    pypi
> tensorflow-io-gcs-filesystem 0.27.0                   pypi_0    pypi
> 

```
import tensorboard as tb
tf.io.gfile = tb.compat.tensorflow_stub.io.gfile

...

tf.io.gfile.MakeDirs(OUTPUT_DIR)
print('***** Model output directory: {} *****'.format(OUTPUT_DIR))

```


### Versions

2022-11-02 21:46:13 (55.1 MB/s) - ‘collect_env.py’ saved [17278/17278]

Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.17

Python version: 3.7.13 (default, Oct 18 2022, 18:57:03)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-52-generic-x86_64-with-debian-bookworm-sid
Is CUDA available: N/A
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: 
GPU 0: NVIDIA RTX A6000
GPU 1: NVIDIA RTX A6000

Nvidia driver version: 510.85.02
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.21.5
[conda] _tflow_select             2.3.0                       mkl  
[conda] blas                      1.0                         mkl  
[conda] cudatoolkit               11.2.2              hbe64b41_10    conda-forge
[conda] mkl                       2021.4.0           h06a4308_640  
[conda] mkl-service               2.4.0            py37h7f8727e_0  
[conda] mkl_fft                   1.3.1            py37hd3c417c_0  
[conda] mkl_random                1.2.2            py37h51133e4_0  
[conda] numpy                     1.21.5           py37h6c91a56_3  
[conda] numpy-base                1.21.5           py37ha15fc14_3  
[conda] tensorflow                1.15.0          mkl_py37h28c19af_0  
[conda] tensorflow-base           1.15.0          mkl_py37he1670d9_0
1.12.1 incompatible with c++ built for 1.12.0 and vice versa
Labels: oncall: jit, module: cpp

### 🐛 Describe the bug

I have a c++/cuda extension which I compile and distribute via PyPI. My build matrix covers all "recent" PyTorch major and minor versions (aswell as python and CUDA versions, if anybody is interest I host my build system as a git workflow [here](https://github.com/charliebudd/torch-extension-builder)). So far this has been enough to ensure my code runs and I have not had to take patch version into account. However, I have recently had an issue (described below) with 1.12.1. My understanding is that only critical bug fixes should be released in patches. If this is not the case, then distributing built c++ PyTorch extensions would be even harder than it currently is.

The error I get is when passing a jit model down to c++. Before 1.12.1, the _c attribute on a jit script model returned a ``torch.jit.ScriptModule`` which will cast to a ``torch::jit::Module`` when passed to a c++ function. However, in 1.12.1, the _c attribute returns a ``torch.ScriptModule`` which no longer casts in the same way, causing an exception to be thrown.

Minimal code example below. To recreate, compile the c++ for torch 1.12.0 and run the python script with torch 1.12.1 and/or vice versa. When the version matches, the code will run fine, else there is an error.
```python
import torch
import myextension

model = torch.jit.load("model.pt")
myextension.test(model._c)
```
```c++
#include <torch/extension.h>

void test_function(torch::jit::Module model)
{
    py::print("Test function called");
}

PYBIND11_MODULE(TORCH_EXTENSION_NAME, m) 
{
    m.def("test", &test_function);
}
```
See forum discussion on this issue [here](https://discuss.pytorch.org/t/version-compatability-scheme-for-pytorch-and-compiled-torch-extensions/164637).



### Versions

torch 1.12.0 and 1.12.1

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel @jbschlosser
Blanket disable torch function/dispatch mode/subclass in dynamo
Labels: triaged, oncall: pt2

I noticed in https://github.com/pytorch/pytorch/pull/88218 that there are a lot of one off DisableTorchFunction all over the torchdynamo codebase. This seems unsustainable. We ought to have some clear invariant about how dynamically scoped state and subclasses affect dynamo. What is this invariant? The obvious one to me is that all modes / context managers are disabled in the compiler, and you explicitly restore the modes if you want to evaluate through them. Is this what we are doing?

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh
[ONNX] Flaky CI test failures with different random seed
Labels: module: onnx, triaged

### 🐛 Describe the bug

Discovered by #88145, when changing random seed from 0 to `SEED` in `common_utils.TestCase`.

Log: https://pipelines.actions.githubusercontent.com/serviceHosts/7d146c05-69c3-4c20-a0e7-818111670117/_apis/pipelines/1/runs/2351893/signedlogcontent/306?urlExpires=2022-11-01T22%3A46%3A31.2721765Z&urlSigningMethod=HMACV1&urlSignature=2frjLmyJUmYOxtaoJCSuZ%2FmDa0skjVVasOLeupl7VJ4%3D

Log segment:
```log
...
2022-11-01T18:07:52.1102989Z Mismatched elements: 1 / 15840 (0.0%)
2022-11-01T18:07:52.1103338Z Greatest absolute difference: 1.3276803656481206e-07 at index (15, 10, 21) (up to 1e-07 allowed)
2022-11-01T18:07:52.1103631Z Greatest relative difference: 0.004392559933859445 at index (15, 10, 21) (up to 0.001 allowed)
2022-11-01T18:07:52.1104300Z [31mFAILED[0m test/onnx/test_pytorch_onnx_onnxruntime.py::[1mTestONNXRuntime_opset_version_17_is_script_False_keep_initializers_as_inputs_False::test_grid_sample_mode_bicubic_padding_mode_border_False[0m - AssertionError: Tensor-likes are not close!
2022-11-01T18:07:52.1104632Z 
2022-11-01T18:07:52.1104720Z Mismatched elements: 4 / 8 (50.0%)
2022-11-01T18:07:52.1104977Z Greatest absolute difference: 0.09897196292877197 at index (0, 0, 1, 0) (up to 0.02 allowed)
2022-11-01T18:07:52.1105259Z Greatest relative difference: 3.0055481606676424 at index (0, 0, 0, 3) (up to 0.02 allowed)
2022-11-01T18:07:52.1105856Z [31mFAILED[0m test/onnx/test_pytorch_onnx_onnxruntime.py::[1mTestONNXRuntime_opset_version_17_is_script_False_keep_initializers_as_inputs_False::test_rpn[0m - AssertionError: Tensor-likes are not close!
2022-11-01T18:07:52.1106146Z 
2022-11-01T18:07:52.1106238Z Mismatched elements: 8 / 3208 (0.2%)
2022-11-01T18:07:52.1106646Z Greatest absolute difference: 92.06178665161133 at index (152, 2) (up to 1e-07 allowed)
2022-11-01T18:07:52.1106931Z Greatest relative difference: 5.274154608570277 at index (152, 0) (up to 0.001 allowed)
2022-11-01T18:07:52.1166774Z [31m========= [31m[1m55 failed[0m, [32m24211 passed[0m, [33m10614 skipped[0m[31m in 661.78s (0:11:01)[0m[31m ==========[0m
```

### Versions

master branch.
Weird random SIGTERM occurance
Labels: oncall: distributed, oncall: r2p

### 🐛 Describe the bug

After training for a few epochs I get thrown an error SIGTERM. There are some models that this happens during training and there are some that this doesn't happen. The error doesn't even tell me which part of my code is causing the problem.

Note: I am using DistributedDataParallel and using torchrun to run my code. The error seems to happen after I replace layernorm with batchnorm.

```
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 59460 closing signal SIGTERM                     [862/1800]
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 59461 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 59462 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 59463 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 59466 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 59470 closing signal SIGTERM
WARNING:torch.distributed.elastic.multiprocessing.api:Sending process 59471 closing signal SIGTERM
ERROR:torch.distributed.elastic.multiprocessing.api:failed (exitcode: 1) local_rank: 5 (pid: 59469) of binary: /home/user/.
conda/envs/deit/bin/python
Traceback (most recent call last):
  File "/home/user/.conda/envs/deit/bin/torchrun", line 8, in <module>
    sys.exit(main())
  File "/home/user/.conda/envs/deit/lib/python3.7/site-packages/torch/distributed/elastic/multiprocessing/errors/__init__.p
y", line 345, in wrapper
    return f(*args, **kwargs)
  File "/home/user/.conda/envs/deit/lib/python3.7/site-packages/torch/distributed/run.py", line 719, in main
    run(args)
  File "/home/user/.conda/envs/deit/lib/python3.7/site-packages/torch/distributed/run.py", line 713, in run
    )(*cmd_args)
  File "/home/user/.conda/envs/deit/lib/python3.7/site-packages/torch/distributed/launcher/api.py", line 131, in __call__
    return launch_agent(self._config, self._entrypoint, list(args))
  File "/home/user/.conda/envs/deit/lib/python3.7/site-packages/torch/distributed/launcher/api.py", line 261, in launch_age
nt
    failures=result.failures,
torch.distributed.elastic.multiprocessing.errors.ChildFailedError:
============================================================
main.py FAILED
------------------------------------------------------------
Failures:
  <NO_OTHER_FAILURES>
------------------------------------------------------------
Root Cause (first observed failure):
[0]:
  time      : 2022-11-01_17:31:08
  host      : host1
  rank      : 5 (local_rank: 5)
  exitcode  : 1 (pid: 59469)
  error_file: <N/A>
  traceback : To enable traceback see: https://pytorch.org/docs/stable/elastic/errors.html
============================================================
```

### Versions

torch==1.10.0
torchvision==0.11.1
timm==0.6.7
transformers==4.5.1

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Add `gloo` support for `all_to_all`
Labels: oncall: distributed, module: c10d

### 🚀 The feature, motivation and pitch

I'm working on a sparse data distribution using collective comms in torchrec. Currently we only use  [`all_to_all_single`](https://github.com/pytorch/pytorch/blob/master/torch/distributed/distributed_c10d.py#L2904) in our sparse data distribution, but we now want to use [`all_to_all`](https://github.com/pytorch/pytorch/blob/master/torch/distributed/distributed_c10d.py#L3035) as well.

Torchrec has built in support for the `gloo` backend, and `all_to_all_single` works with `gloo`; however, `all_to_all` with `gloo` is not supported. We get this error `RuntimeError: ProcessGroup gloo does not support alltoall`.

Since `gloo` supports `all_to_all_single` already, would it be possible to add support for `all_to_all` with `gloo`?

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu 

### Alternatives

_No response_

### Additional context

_No response_
Enable `torch.topk` to support `stable` flag 
Labels: triaged, module: sorting and selection

### 🚀 The feature, motivation and pitch

Referring to issue #88184 
It seems that the sorting algorithm used to implement `topk` is unstable which makes it give unjustifiable results on duplicate elements of input tensor.

Code example
 
```python
import numpy as np
import torch
x = np.array([-1, -1, -1, -1])
for k in range(1, 5):
    val, index =  x[np.argpartition(x, -k)[-k:]], np.argpartition(x, -k)[-k:]
    print(f"top_val: {val}, Index: {index}")
# output
# top_val: [-1], Index: [3]
# top_val: [-1 -1], Index: [2 3]
# top_val: [-1 -1 -1], Index: [1 2 3]
# top_val: [-1 -1 -1 -1], Index: [0 1 2 3]

# torch.topk
y = torch.topk([-1, -1, -1, -1])
for k in range(1, 5):
    val, index =  torch.topk(y, k)
    print(f"top_val: {val}, Index: {index}")
# output
# top_val: tensor([-1]), Index: tensor([2])
# top_val: tensor([-1, -1]), Index: tensor([2, 3])
# top_val: tensor([-1, -1, -1]), Index: tensor([2, 3, 0])
# top_val: tensor([-1, -1, -1, -1]), Index: tensor([2, 3, 0, 1])
```

Adding `stable` functionality must solve this problem.
Thanks.

### Alternatives

_No response_

### Additional context

_No response_