gopikrsmscs/torch-issues huggingface dataset:
Can't export a pth model to onnx (RuntimeError: Couldn't lower all tuples)
Labels: module: onnx

### 🐛 Describe the bug

Hello everyone, I am trying to convert a pytorch model to onnx using the library onnx in torch. The model architecture and weights are in the repository https://github.com/Sense-X/Co-DETR , I am usign the model CO-Dino with a Swin-L backbone, however when I launch the model exportation I encounter this error ```RuntimeError: Couldn't lower all tuples```.

![image](https://github.com/pytorch/pytorch/assets/59453891/62666dfd-e2ff-4ef1-a674-54e8f9ef70ea)

PS: Sorry, I can't copy poste a simple python code to reproduce the problem. 


### Versions

[pip3] numpy==1.24.3
[pip3] onnx==1.14.1
[pip3] onnxruntime==1.8.1
[pip3] onnxruntime-gpu==1.8.1
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl  
[conda] cudatoolkit               11.3.1               h2bc3f7f_2  
[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.24.3           py38h14f4228_0  
[conda] numpy-base                1.24.3           py38h31eccc5_0  
[conda] pytorch                   1.11.0          py3.8_cuda11.3_cudnn8.2.0_0    pytorch
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] torchaudio                0.11.0               py38_cu113    pytorch
[conda] torchvision               0.12.0               py38_cu113    pytorch
[Kineto][NCCL][1/n] Add the world size info in NCCL metadata
Labels: fb-exported, release notes: distributed (c10d)

Summary: This diff adds the world size info in NCCL metadata, as we need the information to calculate the algorithmic bandwidth and bus Bandwidth.

Test Plan:
**Tested together with stacked diffs**:
- Trace: https://fburl.com/perfdoctor/ke1d4g2z
- The information is shown as `Group size` in the trace:
 {F1125504721}

Differential Revision: D50439185
DISABLED test_meta_outplace_fft_ifft_cpu_float64 (__main__.TestMetaCPU)
Labels: triaged, module: flaky-tests, skipped, module: primTorch, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 6 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_meta_outplace_fft_ifft_cpu_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_meta.py`

cc @ezyang @mruberry @Lezcano @peterbell10 @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
Support fp8 in AOTInductor
Labels: module: inductor, ciflow/inductor

Current error: https://gist.github.com/ipiszy/7f8cb8bff482444d299e23735422a236

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #111637



cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
Batched matmul gives incorrect result on MPS devices

### 🐛 Describe the bug

When the dimensions are large enough, batched matmul gives the wrong answer on MPS devices.

Minimal example:

```
import torch

zeros = torch.zeros(911, 9, 1, device=torch.device("mps"))
ones = torch.ones(1, 32769, device=torch.device("mps"))
zeros @ ones
```

This should give a tensor of 0s, but it instead gives a tensor in which 50,505,735 of the entries are 1. If the operation is performed a second time with the same tensors, the number of 1s changes to 182,632,455.

The dimensions in this example are minimal, i.e. the code runs correctly if any of them is made any smaller.

### Versions

PyTorch version: 2.1.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.5.2 (arm64)
GCC version: Could not collect
Clang version: 15.0.0 (clang-1500.0.40.1)
CMake version: version 3.27.7
Libc version: N/A

Python version: 3.10.8 (main, Nov 24 2022, 08:08:27) [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-13.5.2-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M2 Pro

Versions of relevant libraries:
[pip3] flake8==6.1.0
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.1
[pip3] torch==2.1.0
[conda] numpy                     1.26.1                   pypi_0    pypi
[conda] torch                     2.1.0                    pypi_0    pypi
Status Tracker And Summary of Support Needed: Make Dynamo Generated Artifacts Debuggable

Currently, dynamically translated bytecode from Dynamo can only be run as a black box. With the help of recent tools like https://github.com/thuml/depyf , it is possible to decompile bytecode into source code, and to enable debugging tools to debug those generated bytecodes.

This issue (status tracker) ducoments the progress and support needed from PyTorch side to fulfill the goal.

# General idea:

PyTorch generate bytecode (and many other artifacts) dynamically. We can decompile and dump the source code into files, let users set breakpoints, and re-run the program to hit those breakpoints.

# Main difficulty:

In essence, artifacts (transformed bytecode, compiled functions, etc.) are generated **dynamically**. We need to have a stable naming for each artifact so that users can recognize them and reuse them across runs.

# Some minor concerns:

Some function names in Dynamo are not valid (notoriously, the resume functions have `<resume in xxx>` name). We need to assign valid names for them.

# Example usage:

The main usage come from the `depyf` side. The rough idea is to set up a src directory, and dump src there for debugging.

```diff
+ import depyf
+ # set up a hook to dump src of dynamically generated artifacts
+ depyf.enable_torch_compile_debugging(dump_dir="/path/to/dumped/src")
def toy_example(a, b):
    x = a / (torch.abs(a) + 1)
    if b.sum() < 0:
        b = b * -1
    return x * b

for _ in range(100):
    toy_example(torch.randn(10), torch.randn(10))
```

The ideal result looks like this:

![image](https://github.com/pytorch/pytorch/assets/23236638/8f586170-7745-4cf6-9950-2d16fe831a46)

```[tasklist]
### Tasks
- [x] make code name of resume functions valid, finished in https://github.com/pytorch/pytorch/pull/111635 .
```
DISABLED test_narrow_cpu_float64 (__main__.TestNestedTensorDeviceTypeCPU)
Labels: triaged, module: flaky-tests, module: nestedtensor, skipped, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 4 workflow(s) with 12 failures and 4 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_narrow_cpu_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_nestedtensor.py`

cc @cpuhrsch @jbschlosser @bhosmer @drisspg @soulitzer @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
[inductor] Implement clone removal for user defined triton kernel via reinplace_scatters
Labels: ciflow/trunk, module: inductor, module: dynamo, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #111627
* #111434



cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
DISABLED test_meta_outplace_fft_hfft_cpu_uint8 (__main__.TestMetaCPU)
Labels: triaged, module: flaky-tests, skipped, module: primTorch, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 6 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_meta_outplace_fft_hfft_cpu_uint8`
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_meta.py`

cc @ezyang @mruberry @Lezcano @peterbell10 @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
Missing `ignored_param` when calling wrapper_cls (FSDP) recursively
Labels: oncall: distributed, triaged

https://github.com/pytorch/pytorch/blob/935f6977542affc0d16c66333a13d60dae6aa5fa/torch/distributed/fsdp/wrap.py#L561

When calling FSDP class recursively, `ignored_param` (which is supposed to be passed by `ignored_states`) seems to be missing. When I pass parameters to ignore to FSDP, this information is lost at this interface when calling FSDP class recursively. 

I think `ignored_states` should be re-defined here and should be part of `kwargs`.

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu
[5/N] Make torch context manager a TorchCtxManagerClassVariable
Labels: topic: not user facing, module: dynamo, ciflow/inductor

Major change in this PR is to make torch context manager class a separate ```TorchCtxManagerClassVariable```, since we have dynamo implementation for these ctx managers.

I was thinking to wrap them as ```UserDefinedClassVariable``` and do dispatch at ```USCVariable.call_function```, but it seems almost the same amount of work and this way is more clear.

This is on the way of moving ```TorchVariable``` to ```TorchFunctionVariable``` which will only handle the functions who would be allowed in graph (e.g, ```torch.sin```) and constant folded (e.g, ```torch.is_floating_point```). All other torch functions would be go through skip/inline rules, and would be wrapped as ```UserFunctionVariable``` (for inlined) and ```SkipFilesVariable``` (for skipped).
The next steps:
* Wrap torch modules, classes, objects as regular ```PythonModuleVariable```, ```UserDefinedClassVariable``` and ```UserDefinedObjectVariable```. 
* Generate the allow in graph torch functions list and wrap them as ```TorchFunctionVariable```.
* Finally merge ```skipfiles.check``` and ```is_allowed``` into one function ```allow_skip.check(fn)``` which would return a Enum of allow, skip and inline. 


cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
maximum Python version supported is not indicated
Labels: module: docs, triaged

### 📚 The doc issue

https://pytorch.org/get-started/locally/

Python 3.12 has been released, but it's not supported by the PyTorch wheels. This is not indicated on the page. Only the minimum Python version is indicated 

### Suggest a potential alternative/fix

Indicate both min and max Python versions supported when installing via pip.

cc @svekars @carljparker
DISABLED test_cat_nhwc (__main__.TestQuantizedOps)
Labels: triaged, module: macos, skipped

Platforms: macos

This test was disabled because it is failing on main branch ([recent examples](http://torch-ci.com/failure/test_quantization.py%3A%3ATestQuantizedOps%3A%3Atest_cat_nhwc)).

This periodic test looks flaky over the past few weeks.

cc @malfet @albanD
[dynamo] fix None routing bug during var_getattr on UDO
Labels: ciflow/trunk, topic: not user facing, module: dynamo, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* #111726
* #111725
* #111415
* __->__ #111614
* #111717
* #111306



cc @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
[AOTInductor] Enforce no_grad for Run entries
Labels: topic: not user facing, module: inductor, ciflow/inductor

Summary:
Always enter no_grad mode in AOTInductor run entries.

```
// AOTInductor uses at::addmm_out, which doesn't supports
// arguments that requires gradient. For this reason, we
// enforce no_grad context for run APIs.
```

Test Plan:
buck2 test mode/dev-nosan caffe2/test/inductor:test_aot_inductor

and OSS CI

Differential Revision: D50432042




cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
[HigherOrderOp] don't mannually set input for cond
Labels: ciflow/trunk, module: dynamo, ciflow/inductor, module: higher order operators

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #111611
* #111610

We set mannualy_set_graph_inputs to False for CondHigherOrder. After that, it became necessary to deduplicate the inputs.  We'll add pytree tests in the follow-up pr.

Test Plan:
existing tests.


cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng @zou3519
[Pytorch][Vulkan] mean.dim
Labels: fb-exported, module: vulkan, release notes: vulkan, ciflow/periodic

Summary:
We implement [`torch.mean(input, dim, keepdim)`](https://pytorch.org/docs/stable/generated/torch.mean.html) for tensors of 2d to 4d.

Since 0-dim tensor hasn't been supported yet, we only support `dim.size() < input.dim()` for now. We will support following cases in the future work:
- `dim.size() == input.dim()`
- `input.dim() == 1`

Test Plan:
```
[luwei@devbig984.prn1 /data/users/luwei/fbsource (970fcd90c)]$ LD_LIBRARY_PATH=third-party/swiftshader/lib/linux-x64/ buck run fbcode/mode/dev-nosan //xplat/caffe2:pt_vulkan_api_test_bin -- --gtest_filter="*mean*"
Building: finished in 0.1 sec (100%) 339/339 jobs, 0/339 updated
  Total time: 0.1 sec
BUILD SUCCEEDED
Running main() from third-party/googletest/1.11.0/googletest/googletest/src/gtest_main.cc
Note: Google Test filter = *mean*
[==========] Running 7 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 7 tests from VulkanAPITest
[ RUN      ] VulkanAPITest.mean_invalid_inputs
[       OK ] VulkanAPITest.mean_invalid_inputs (46 ms)
[ RUN      ] VulkanAPITest.mean_dim_2d
[       OK ] VulkanAPITest.mean_dim_2d (127 ms)
[ RUN      ] VulkanAPITest.mean_dim_3d
[       OK ] VulkanAPITest.mean_dim_3d (103 ms)
[ RUN      ] VulkanAPITest.mean_dim_4d
[       OK ] VulkanAPITest.mean_dim_4d (89 ms)
[ RUN      ] VulkanAPITest.mean_dim_keepdim_2d
[       OK ] VulkanAPITest.mean_dim_keepdim_2d (66 ms)
[ RUN      ] VulkanAPITest.mean_dim_keepdim_3d
[       OK ] VulkanAPITest.mean_dim_keepdim_3d (127 ms)
[ RUN      ] VulkanAPITest.mean_dim_keepdim_4d
[       OK ] VulkanAPITest.mean_dim_keepdim_4d (4 ms)
[----------] 7 tests from VulkanAPITest (564 ms total)

[----------] Global test environment tear-down
[==========] 7 tests from 1 test suite ran. (564 ms total)
[  PASSED  ] 7 tests.
```

Reviewed By: yipjustin

Differential Revision: D50312990
DISABLED test_meta_outplace_fft_hfft_cpu_float64 (__main__.TestMetaCPU)
Labels: triaged, module: flaky-tests, skipped, module: primTorch, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 10 workflow(s) with 30 failures and 10 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_meta_outplace_fft_hfft_cpu_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_meta.py`

cc @ezyang @mruberry @Lezcano @peterbell10 @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
DISABLED test_narrow_cpu_float32 (__main__.TestNestedTensorDeviceTypeCPU)
Labels: triaged, module: flaky-tests, module: nestedtensor, skipped, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 5 workflow(s) with 15 failures and 5 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_narrow_cpu_float32`
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_nestedtensor.py`

cc @cpuhrsch @jbschlosser @bhosmer @drisspg @soulitzer @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
Add aot inductor test for dynamic batch size
Labels: ciflow/trunk, topic: not user facing, module: inductor

Summary:

add aot inductor test for dynamic batch size

Test Plan:

```
python test/inductor/test_aot_inductor.py  -k test_dynamic_batch_sizes
```



cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
Revert "Revert "Nvfuser code removal (#111093)""
Labels: triaged, open source, module: amp (automated mixed precision), ciflow/trunk, release notes: jit

This reverts commit 715dfced72657e5adacd5bef16e3d458cd94851b.

The original PR #111093 is reverted due to broken internal build.


cc @mcarilli @ptrblck @leslie-fang-intel @jgong5
Add testing for foreach scalar Tensor overloads in inductor
Labels: ciflow/trunk, topic: not user facing, module: inductor, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #111600
* #111084
* #111079



cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
Apply same 'pick_grad' on generating fp64 reference outputs
Labels: open source, module: dynamo, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* #108294
* __->__ #111593

To lower memory consumption for inference mode.

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
[inductor][easy] skip test_extension_backend.py in fbcode
Labels: fb-exported, topic: not user facing, module: inductor

Summary: It's currently failing. We should skip it in fbcode because cpp extensions don't work right now.

Differential Revision: D48852412




cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
wip
Labels: module: inductor, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* #111459
* #111402
* __->__ #111587



cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
Use 'device' argument  in test_sparse.py::TestSparseAnyCUDA::test_as_sparse_gradcheck_*
Labels: open source, ciflow/trunk, topic: not user facing, ciflow/periodic, ciflow/rocm

Argument "device" was missed.
So, "test_sparse.py::TestSparseAnyCUDA::test_as_sparse_gradcheck_*_cuda" was always run on the default device ("cpu") if another default torch device was not configured before. 
This fix will probably detect a number of issues on various devices which were previously missed.
Should fix failed rocm CI jobs with "##[error]The action has timed out."  and speedup test execution
DISABLED test_vmapjvpall_linalg_det_singular_cpu_float32 (__main__.TestOperatorsCPU)
Labels: triaged, module: macos, skipped

Platforms: macos

This test was disabled because it is failing on main branch ([recent examples](http://torch-ci.com/failure/functorch%2Ftest_ops.py%3A%3ATestOperatorsCPU%3A%3Atest_vmapjvpall_linalg_det_singular_cpu_float32)).

cc @malfet @albanD
Dynamic shapes doesn't work for torch.diff / resize__symint in some cases
Labels: oncall: pt2, module: dynamic shapes

```python
a = torch.tensor([0, 2])
b = torch.tensor([1])

def fn(a, b):
    a = a.clone()
    b = b.clone()
    torch.diff(a, n=0, out=b)
    return b

compiled_f = torch.compile(fn, fullgraph=True, backend="eager", dynamic=True)
out = compiled_f(a, b)

# Works
a = torch.tensor([0, 3, 4]) # size changed
b = torch.tensor([1]) # size is the same
out = compiled_f(a, b)

# Doesn't work
a = torch.tensor([0, 3, 4]) # size changed
b = torch.tensor([1, 2]) # size changed
out = compiled_f(a, b)
```

Versions: main after https://github.com/pytorch/pytorch/pull/111530

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
Prolonged network hiccup preventing retrieval of workflow job id
Labels: triaged, module: devx

Please see https://github.com/pytorch/pytorch/pull/111483 for context

First known bad is https://hud.pytorch.org/pytorch/pytorch/commit/e0b035c220a4db2a15b53848cd16ac6416fcf323
Got fixed in https://hud.pytorch.org/pytorch/pytorch/commit/543dc757463aa0ad559c49337c98eece6a25150f?

~How is it that the second I notice it happening it gets fixed... Some quantum observation thing going on here...~

cc @ZainRizvi @kit1980 @huydhn
DISABLED test_meta_outplace_fft_hfft_cpu_complex64 (__main__.TestMetaCPU)
Labels: triaged, module: flaky-tests, skipped, module: primTorch, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 6 workflow(s) with 18 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_meta_outplace_fft_hfft_cpu_complex64`
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_meta.py`

cc @ezyang @mruberry @Lezcano @peterbell10 @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
Tensor `.cuda()` very slow with specific array sizes 
Labels: module: performance, module: cuda, triaged

### 🐛 Describe the bug

I've been profiling some streaming code and found a strange case where copying a tensor to the GPU is much slower for specific array sizes.

This is specific to arrays that are fortran-ordered to begin with and the issue is mitigated by calling `.clone()` on the tensor before `.cuda()`.

```
rows = 327680   # 2 ** 16 * 5
np_arr = np.asfortranarray(np.random.randn(rows, 2000).astype(np.float32))
arr = torch.from_numpy(np_arr)
x = arr[10_000: 50_000]   # grab a subset of 40k rows

%%time
_ = x.cuda()
```

This takes around 800ms on my machine.

With `rows = 327680 - 1`, it takes 280ms on my machine.
With `rows = 327680 + 1`, it takes 170ms on my machine.
With `rows = 100000`, it takes 80ms on my machine.

In all cases, adding a `.clone()` prior to `.cuda()` seems to reduce the time to around 80ms. In general it seems that multiples of 2^16 perhaps perform slower (I've tried with 2^16 and 2^16 - 1 and there seems to be a significant difference).

### Versions

Collecting environment information...
PyTorch version: 2.1.0+cu118
Is debug build: False
CUDA used to build PyTorch: 11.8
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.3 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.35

Python version: 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] (64-bit runtime)
Python platform: Linux-5.15.86-flatcar-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 11.7.99
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: NVIDIA A100-SXM4-80GB
Nvidia driver version: 470.103.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Address sizes:                   48 bits physical, 48 bits virtual
Byte Order:                      Little Endian
CPU(s):                          128
On-line CPU(s) list:             0-127
Vendor ID:                       AuthenticAMD
Model name:                      AMD EPYC 7542 32-Core Processor
CPU family:                      23
Model:                           49
Thread(s) per core:              2
Core(s) per socket:              32
Socket(s):                       2
Stepping:                        0

Versions of relevant libraries:
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.1
[pip3] pytorch-lightning==2.1.0
[pip3] torch==2.1.0+cu118
[pip3] torchmetrics==1.2.0
[pip3] triton==2.1.0
[conda] Could not collect

cc @ptrblck
[dynamo] so-called global state guard is installed on global, when in fact values are thread-local
Labels: oncall: pt2

### 🐛 Describe the bug

https://github.com/pytorch/pytorch/blob/971f67c9880b4037064b4bd24b858c80e6c69174/torch/_dynamo/convert_frame.py#L113

https://github.com/pytorch/pytorch/blob/971f67c9880b4037064b4bd24b858c80e6c69174/torch/_dynamo/convert_frame.py#L377

This means that we are not thread-safe with respect to compiling multiple functions at once across different threads.

### Specific Scenarios

For instance, one call to compile may set a new global state based on its thread-local values, and then another thread reads off those values when it is instantiating or checking a guard.

### Details

See that many of the values it captures:
https://github.com/pytorch/pytorch/blob/971f67c9880b4037064b4bd24b858c80e6c69174/torch/csrc/dynamo/guards.cpp#L438

Are in fact thread-local values:

https://github.com/pytorch/pytorch/blob/fa995626a8e181e3666b27fdb4edbe6116b22ee3/c10/core/AutogradState.h#L13

### Versions

main

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @voznesenskym
DISABLED test_narrow_cpu_float16 (__main__.TestNestedTensorDeviceTypeCPU)
Labels: triaged, module: flaky-tests, module: nestedtensor, skipped, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 6 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_narrow_cpu_float16`
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_nestedtensor.py`

cc @cpuhrsch @jbschlosser @bhosmer @drisspg @soulitzer @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
build: failure when building pytorch with TBB
Labels: module: build, triaged, module: tbb


## Issue description

I want to build pytorch from source using TBB but not OMP, and I try v1.10.2 and v1.13.1, both failed. plz help.


## Code example

Error messages:
```
[ 98%] Linking CXX executable ../../../../bin/torch_shm_manager
/data/wangjie/dependtool/pytorch/build/lib/libtorch_cpu.so：对‘std::allocator<std::pair<long, std::tuple<torch::jit::SourceRange, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, c10::intrusive_ptr<torch::jit::InlinedCallStack, c10::detail::intrusive_target_default_null_type<torch::jit::InlinedCallStack> > > > >::allocator()’未定义的引用
collect2: error: ld returned 1 exit status
```

- PyTorch or Caffe2:
- How you installed PyTorch (conda, pip, source): source
- Build command you used (if compiling from source): USE_CUDA=0 BUILD_TEST=0 USE_TBB=1 USE_OPENMP=0 MKLDNN_CPU_RUNTIME=TBB MKL_THREADING=TBB ATEN_THREADING=TBB  python setup.py install
- OS: centos7
- PyTorch version: v1.13.1 & v1.10.2
- Python version: 3.10.13
- CUDA/cuDNN version:
- GPU models and configuration:
- GCC version (if compiling from source):3.7.0
- CMake version:3.21.0
- Libc version: glibc-2.17
- Versions of any other relevant libraries:


cc @malfet @seemethere
Higher-order derivatives extremely slow, increasing exponentially
Labels: module: autograd, triaged, needs research

### 🐛 Describe the bug

In my application, I need to take the nth order mixed derivative of a function. However, I found that the torch.autograd.grad computation time increases exponentially as n increases. Is this expected, and is there any way around it?

This is my code for differentiating a function self.F (from R^n -> R^1):

```
def differentiate(self, x):
    x.requires_grad_(True)
    xi = [x[...,i] for i in range(x.shape[-1])]
    dyi = self.F(torch.stack(xi, dim=-1))
    for i in range(self.dim):
        start_time = time.time()
        dyi = torch.autograd.grad(dyi.sum(), xi[i], retain_graph=True, create_graph=True)[0]
        grad_time = time.time() - start_time
        print(grad_time)
    return dyi
```

And these are the times printed for each iteration of the above loop:
```
0.0037012100219726562
0.005133152008056641
0.008165121078491211
0.019922733306884766
0.059255123138427734
0.1910409927368164
0.6340939998626709
2.1612229347229004
11.042078971862793
```

I assume this is because the size of the computation graph is increasing? Is there any way around this? I thought I might be able to circumvent this issue by taking a functional approach (presumably obviating the need for a computation graph), using torch.func.grad. However, this actually increased the runtime of the same code! Am I not understanding torch.func.grad properly?

### Versions

torch 2.1.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
[dynamo] `not aliased -> aliased` Guard only implemented for Tensors
Labels: oncall: pt2

### 🐛 Describe the bug

For tensors, both `aliased -> not aliased` and `not aliased -> aliased` can lead to guard failure.
- `aliased -> not aliased`: L['x'] is L['y']"
- `not aliased -> aliased`: Duplicate tensor found where not expected! L['y']should not alias to anything, but is aliased"

For other objects, only `aliased -> not aliased`
- `aliased -> not aliased`: L['x'] is L['y']"

### Diagnosis

This is due to the guards deduping tensors:
https://github.com/pytorch/pytorch/blob/aa3243bceb8c84f56f326b9e8c60ecc9794bbce4/torch/csrc/dynamo/guards.cpp#L404
But not objects

### Question:
1. If there is 1 alias, which then increases to 2, will it still trigger recompile? Yes:
```python
def fn(z, x, y):
    if x is y:
        return z + x * 2
    else:
        return z + x + y

fn_opt = torch.compile(backend='eager', fullgraph=True, dynamic=True)(fn)

x = torch.zeros(2)
y = torch.ones(2)

self.assertEqual(fn(x, x, y), fn_opt(x, x, y))
self.assertEqual(fn(x, x, x), fn_opt(x, x, x))
```

### Versions

main

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
DISABLED test_meta_outplace_addmm_decomposed_cpu_complex64 (__main__.TestMetaCPU)
Labels: triaged, module: flaky-tests, skipped, module: primTorch, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 6 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_meta_outplace_addmm_decomposed_cpu_complex64`
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_meta.py`

cc @ezyang @mruberry @Lezcano @peterbell10 @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
[RFC] Add GradScaler on CPU
Labels: triaged, module: half

### 🚀 The feature, motivation and pitch

To enable FP16 support on CPU https://github.com/pytorch/pytorch/issues/97068, GradScaler is necessary for FP16 training to prevent grad overflows.


### Alternatives

* Step1: Add the corresponding kernels of `_amp_foreach_non_finite_check_and_unscale_` and `_amp_update_scale_kernels` on CPU
Follow the implements of CUDA.
* Step2: Frontend API for GradScaler on CPU:
 1: Move the common logic codes of GradScaler to a file `torch/amp/grad_scaler.py`. Most parts of GradScaler can be abstracted as a base class since the algorithm of GradScaler is same on CPU and CUDA.  
 2: Add 2 derived class for CPU and CUDA to set device related config.
The design of Frontend API for GradScaler  is same as autocast.

* API usage:

```Python
# Creates a GradScaler once at the beginning of training.

# Before: only available on CUDA
# scaler = torch.cuda.amp.GradScaler()

# After: available on CUDA and CPU
# scaler = torch.cuda.amp.GradScaler()
scaler = torch.cpu.amp.GradScaler()
for epoch in epochs:
    for input, target in data:
        optimizer.zero_grad()
        output = model(input)
        loss = loss_fn(output, target)

        # Scales loss.  Calls backward() on scaled loss to create scaled gradients.
        scaler.scale(loss).backward()

        # scaler.step() first unscales gradients of the optimizer's params.
        # If gradients don't contain infs/NaNs, optimizer.step() is then called,
        # otherwise, optimizer.step() is skipped.
        scaler.step(optimizer)

        # Updates the scale for next iteration.
        scaler.update()
```




### Additional context

This RFC depends on FP16 supports for operators https://github.com/pytorch/pytorch/issues/97068 and FP16 support of autocast on CPU https://github.com/pytorch/pytorch/issues/96093
[dynamo] Implement `set.__contains__` for tensors based on object identity
Labels: oncall: pt2

### 🚀 The feature, motivation and pitch

Workaround to https://github.com/pytorch/pytorch/issues/111544 for `set.__contains__` case

### Alternatives

_No response_

### Additional context

Related https://github.com/pytorch/pytorch/issues/111550

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
Fix inconsistency of max_split_size between DeviceStats and CUDAAllocatorConfig
Labels: open source, ciflow/binaries, topic: not user facing

CUDAAllocatorConfig uses size_t max_split_size and initializes it to std:: numeric_limits<size_t>::max(), and then the value is assigned to max_split_size of DeviceStats which is of type int64_t, so that the command 
```
python3 -c "import torch;y=torch.empty(3,device='cuda');print(torch.cuda.memory_stats(0)['max_split_size'])"
```
returned -1.

After skimming through the code, and reading the doc in https://pytorch.org/docs/stable/generated/torch.cuda.memory_stats.html, It was sure that negative values of max_split_size make no sense and we should use size_t instead. Now the error has been fixed and the command returns std:: numeric_limits<size_t>::max().

This issue was found in revert of #111137

cc @malfet
[dynamo] Implement full `is_` checking
Labels: oncall: pt2, module: dynamo

### 🚀 The feature, motivation and pitch

This requires checking equality of objects.

For consts, this just requires checking the backing const.

~~For `VariableTracker`s with sources, this requires checking the sources. I believe we do not need to actually reference the original object. Hope this is right? @voznesenskym~~ 

source is not always available. `example_value` `FakeTensor` is better.

### Alternatives

Users cannot do things like deduplicate tensors or other objects in traced code

### Additional context

Required for properly tracing `nn.modules`: https://github.com/pytorch/pytorch/pull/111548
Related: https://github.com/pytorch/pytorch/issues/109504

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
DISABLED test_detach_cpu_float64 (__main__.TestNestedTensorDeviceTypeCPU)
Labels: triaged, module: flaky-tests, module: nestedtensor, skipped, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 4 workflow(s) with 12 failures and 4 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_detach_cpu_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_nestedtensor.py`

cc @cpuhrsch @jbschlosser @bhosmer @drisspg @soulitzer @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
[dynamo] `set.__contains__` is not properly implemented for tensors,  by virtue of `eq(Tensor, Tensor)` being inconsistently implemented
Labels: oncall: pt2

### 🐛 Describe the bug

```python
param = torch.zeros(5)
param2 = torch.zeros(5)

tensor_list = set()
tensor_list.add(param2)
print(param2 in tensor_list)  # False

def fn(param, param2):
    tensor_list = set([param2])
    return param in tensor_list 

ret = torch.compile(fn, onegraph=True)(param, param2)
```

```
torch._dynamo.exc.Unsupported: comparison TensorVariable() <built-in function eq> TensorVariable()
```

Inconsistent behaviour
```python
param = torch.zeros(5)
param2 = torch.zeros(5)

tensor_list = set()
tensor_list.add(param2)
print(param2 in tensor_list)  # False

def fn(param, param2):
    tensor_list = set([param2])
    return param in tensor_list

ret = torch.compile(fn, fullgraph=True)(param, param2)
assert ret == fn(param, param2)   # RuntimeError: Boolean value of Tensor with more than one value is ambiguous

```

Root cause: `__contains__` based on equality of tensors has inconsistent behaviour due to overloading eq https://github.com/pytorch/pytorch/issues/111542

### Versions

main

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519
Propose to add constant padding mode to the `torch.nn.functional.grid_sample` function
Labels: module: nn, triaged

### 🚀 The feature, motivation and pitch

I'm working on a registration project. When I am using `torch.nn.functional.grid_sample` to apply the displacement field to the moving image, I find I am unable to use constant values like 255 to pad it (at least it is not that intuitive) just like the way in `np.pad`. So I propose to add one. If possible I would really want to implement it myself, though I am a completely new contributor to the pytorch project.

### Alternatives

As a workaround, I pre-pad the image with 255 pixels on the border and use the `border` mode.

### Additional context

Here are two samples,
![`zeros` mode](https://github.com/pytorch/pytorch/assets/54883050/aa30dc3e-ab8d-4b24-9b11-8b2357e09c8d)
![pre-pad `border` mode](https://github.com/pytorch/pytorch/assets/54883050/9ddca4f5-f7bc-48ca-bb33-5474254b1e23)


cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
[Pytorch][CPU] Switch building compiler to Clang
Labels: fb-exported, module: inductor, ciflow/inductor

Summary:
The slimdsnn model is currently built with GCC, and I see Clang-15 generates better code than GCC which is 10% faster, after a stack of backporting (D50338220).

There are likely other improvements to internal Clang as the TOT Clang in LLVM upstream generates even better code.

Test Plan:
Before:

   buck2 run mode/{opt,inplace} //accelerators/workloads/models/slimdsnn:slimdsnn_dso_benchmark -- --iterations=100000000

   Starting benchmark, 100000000 iterations...
   Batch=1 latency: 0.643 us

After:

   buck2 run mode/{opt,inplace} //accelerators/workloads/models/slimdsnn:slimdsnn_dso_benchmark -- --iterations=100000000

   Starting benchmark, 100000000 iterations...
   Batch=1 latency: 0.593  us

Reviewed By: bertmaher

Differential Revision: D50399150




cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
DISABLED test_Conv2d_naive_groups_cuda_float16 (__main__.TestConvolutionNNDeviceTypeCUDA)
Labels: module: rocm, triaged, skipped

Platforms: rocm

Failure observed in ROCm5.7 CI upgrade PR, so skipping until resolved: https://github.com/pytorch/pytorch/pull/110465#issuecomment-1758427256

cc @jeffdaily @sunway513 @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
DISABLED test_meta_outplace_addmm_decomposed_cpu_complex128 (__main__.TestMetaCPU)
Labels: module: flaky-tests, skipped, oncall: pt2

Platforms: dynamo

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

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 6 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_meta_outplace_addmm_decomposed_cpu_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_meta.py`

ConnectionTimeoutError: Connect timeout for 5000ms, GET https://raw.githubusercontent.com/pytorch/pytorch/main/test/test_meta.py -2 (connected: false, keepalive socket: false, socketHandledRequests: 1, socketHandledResponses: 0)
headers: {}

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305
[dynamo] Fix context wrapping grad mode variable
Labels: triaged, open source, topic: not user facing, module: dynamo, ciflow/inductor

Fixes https://github.com/pytorch/pytorch/issues/111528

Makes use of `ContextWrappingVariable` so that the function will enter the grad mode whenever it is called, and exit once it is done calling.


cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
DISABLED test_Conv2d_groups_nobias_v2 (__main__.TestConvolutionNN)
Labels: module: rocm, triaged, skipped

Platforms: rocm

Failure observed in ROCm5.7 CI upgrade PR, so skipping until resolved: https://github.com/pytorch/pytorch/pull/110465#issuecomment-1758427256

cc @jeffdaily @sunway513 @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
DISABLED test_Conv2d_groups_nobias (__main__.TestConvolutionNN)
Labels: module: rocm, triaged, skipped

Platforms: rocm

Failure observed in ROCm5.7 CI upgrade PR, so skipping until resolved: https://github.com/pytorch/pytorch/pull/110465#issuecomment-1758427256

cc @jeffdaily @sunway513 @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Add compile support for NT unbind
Labels: module: dynamo

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #111531
* #111530
* #111529



cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng