gopikrsmscs/torch-issues huggingface dataset:
The API "torch::jit::_load_for_mobile" is limited to create an object living on the stack.
Labels: oncall: jit

### 🐛 Describe the bug

To load a jit module using LibTorch-Lite under iOS, the standard way is the following method:

```
auto model = torch::jit::_load_for_mobile(modelPath, torch::kCPU);
```

However, this method is highly limited. It can only create a stack object.
By stack object, I mean the difference between:
```
void test() {
    Foo a;
    Foo *b = new Foo();
}
```
In the above example, "a" is a stack object, "b" is a heap object, which means I can hold "b" and repeatedly invoke method on "b".  Whereas "a" is automatically released when leaving the code block of the "test" function.

The same problem goes with the API "_load_for_mobile". Since "_load_for_mobile" can only create stack object, the developer can't hold the loaded jit module. It indicates that each time I want to do a prediction, I have to load the jit module on the fly which puts extra overhead time before each prediction.

Do we have any method to load a jit module into heap memory?

### Versions

LibTorch-Lite (1.13.0.1)

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Unable to install the latest version of PyTorch using mamba.
Labels: oncall: binaries

### 🐛 Describe the bug

I am encountering an issue while using mamba to install the latest version of PyTorch. The problem is that after mamba completes the download of the PyTorch package, it automatically terminates the current terminal process, causing it to switch to another terminal.

![image](https://github.com/pytorch/pytorch/assets/96970081/c39a0d62-136b-4dca-a545-d73e4dca2f5a)


### Versions

conda 23.3.1

cc @seemethere @malfet
Cannot construct `torch.sparse_coo_tensor` (but `scipy.sparse.coo_matrix` works fine): `TypeError: only integer tensors of a single element can be converted to an index`
Labels: module: sparse, triaged, module: scipy compatibility

### 🐛 Describe the bug

Also, note the strange warning when using `weights_only=True`.
[bug.pt.gz](https://github.com/pytorch/pytorch/files/12586855/bug.pt.gz)

```python
import gzip
import torch
import scipy

bug = torch.load(gzip.open('bug.pt.gz', 'rb'), weights_only=True)
#  /home/vadimkantorov/.local/lib/python3.8/site-packages/torch/_utils.py:841: UserWarning: TypedStorage is deprecated. It will be removed in the future and UntypedStorage will be the only storage class. This should only matter to you if you are using storages directly.  To access UntypedStorage directly, use tensor.untyped_storage() instead of tensor.storage()
#  return self.fget.__get__(instance, owner)()

scipy.sparse.coo_matrix((bug['values'], (bug['rowinds'], bug['colinds'])), shape=bug['shape'])
# ok

torch.sparse_coo_tensor((bug['rowinds'], bug['colinds']), bug['values'], size=bug['shape'])
# TypeError: only integer tensors of a single element can be converted to an index
```

Same error appears in https://github.com/pytorch/pytorch/issues/43949 in a completely different context. This error is extremely mysterious and weird.

### Versions

2.1.0.dev20230802+cpu

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer
FSDP do not support `ignored_parameters` when `auto_wrap_policy` is specified
Labels: oncall: distributed, triaged, module: fsdp

### 🐛 Describe the bug

I have a model which contains some params need to be ignored ( else flat_param will raise an error), the construction code is like:

```
        not_trainable = []
        for name, p in model.named_parameters():
            if p.requires_grad == False:
                not_trainable.append(p)
        sharding_strategy=torch.distributed.fsdp.ShardingStrategy._HYBRID_SHARD_ZERO2
        model = FSDP(model, sharding_strategy=sharding_strategy,
                     ignored_parameters = not_trainable,
                     auto_wrap_policy=size_based_auto_wrap_policy)

```
I came across an error: the params in `not_trainable ` would cause error when executing `_init_flat_param`.

If `auto_wrap_policy` is not passed, the code works.

### Versions

PyTorch version: 2.0.1+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: CentOS Linux 7 (Core) (x86_64)
GCC version: (GCC) 10.2.0

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin
Can't initializa NVML
Labels: triaged

### 🐛 Describe the bug


>>> import torch
>>> torch.__version__
'2.0.1+cu117'
>>> torch.cuda.device_count()
/opt/conda/lib/python3.10/site-packages/torch/cuda/__init__.py:546: UserWarning: Can't initialize NVML
  warnings.warn("Can't initialize NVML")
0
>>> torch.cuda.is_available()
False


### Versions


>>> import torch
>>> torch.__version__
'2.0.1+cu117'
>>> torch.cuda.device_count()
/opt/conda/lib/python3.10/site-packages/torch/cuda/__init__.py:546: UserWarning: Can't initialize NVML
  warnings.warn("Can't initialize NVML")
0
>>> torch.cuda.is_available()
False
why is that?
[WIP] Use user directed names for variables where possible
Labels: module: dynamo, ciflow/inductor

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



cc @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
DISABLED test_out_randn_cuda_float32 (__main__.TestCommonCUDA)
Labels: high priority, triaged, skipped, oncall: pt2

Platforms: inductor
See https://github.com/pytorch/pytorch/issues/109061
This test was disabled because it is failing on main branch ([recent examples](http://torch-ci.com/failure/test_ops.py%3A%3ATestCommonCUDA%3A%3Atest_out_randn_cuda_float32)).

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @wconstab @bdhirsh @anijain2305
torch.argmax fails for device='mps:0'
Labels: triaged, module: mps

### 🐛 Describe the bug

torch.argmax gives wrong results for mps device. 

```
>>> import torch
>>> torch.backends.mps.is_available()
True
>>> device='mps:0'
>>> y = torch.tensor([14, 13, 11], dtype=torch.int, device=device)
>>> y
tensor([14, 13, 11], device='mps:0', dtype=torch.int32)
>>> i = torch.argmax(y, dim=0)
>>> i
tensor(-9223372036854775808, device='mps:0')
>>> 
```
Should give `i=0`
It works when `device='cpu'`:
```
>>> y = torch.tensor([14, 13, 11], dtype=torch.int, device='cpu')
>>> y
tensor([14, 13, 11], dtype=torch.int32)
>>> i = torch.argmax(y, dim=0)
>>> i
tensor(0)
```

### Versions

>: python collect_env.py
Collecting environment information...
PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.5.1 (x86_64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: Could not collect
Libc version: N/A

Python version: 3.11.4 (main, Jul 15 2023, 12:21:29) [Clang 14.0.3 (clang-1403.0.22.14.1)] (64-bit runtime)
Python platform: macOS-13.5.1-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz

Versions of relevant libraries:
[pip3] numpy==1.25.1
[pip3] torch==2.0.1
[pip3] torchvision==0.15.2
[conda] Could not collect


cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
Faster gc_count update for CUDACachingAllocator (and avoid nullptr dereference)
Labels: fb-exported

Summary:
Modify the way we update gc_count in CUDACachingAlloctor to make it faster.

Originally D48481557, but reverted due to nullptr dereference in some cases (D49003756).
This diff changed to use correct constructor for search key (so avoid nullptr dereference). Also, added nullptr check (and returns 0 if it is) in gc_count functions.

Differential Revision: D49068760
CollectiveFunctionRewriteVariable for all_to_all_single
Labels: triaged, oncall: pt2, module: dynamo

### 🐛 Describe the bug

https://github.com/pytorch/pytorch/pull/106655 doesn't currently have the rewriting logic that will make it used even if you use the non-functional collective. Add this logic. To do this we may need to list-ify the input/output sizes first.

cc @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng @yf225 

### Versions

main
UserError: Can't call type() on generated custom object. Please use __class__ instead
Labels: good first issue, triaged, oncall: pt2, module: dynamo

### 🐛 Describe the bug

```
    File "/data/users/ezyang/b/pytorch/torch/_dynamo/symbolic_convert.py", line 1119, in CALL_FUNCTION                                 self.call_function(fn, args, {})                                                                                           
    File "/data/users/ezyang/b/pytorch/torch/_dynamo/symbolic_convert.py", line 565, in call_function                                  self.push(fn.call_function(self, args, kwargs))                                                                            
    File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/builtin.py", line 618, in call_function                                 result = handler(tx, *args, **kwargs)                                                                                      
    File "/data/users/ezyang/b/pytorch/torch/_dynamo/variables/builtin.py", line 1220, in call_type                              
      raise UserError(                                                                                                           
  torch._dynamo.exc.UserError: Can't call type() on generated custom object. Please use __class__ instead 
```

this error seems nonsensical to me, we should just support it

showed up in torchrec `dist_data.py`

```
        return type(self._input).dist_init(
            keys=self._keys,
            tensors=self._output_tensors,
            batch_size_per_rank=self._batch_size_per_rank,
            recat=self._recat,
        )
```

### Versions

main

cc @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
AOTAutograd view-replay logic does not handle dtype views well
Labels: high priority, triaged, oncall: pt2, module: aotdispatch

Example repro from @bertmaher:
```
print(lambda x: x.view(torch.int32)(torch.ones(8))
print(torch.compile(lambda x: x.view(torch.int32), backend="aot_eager")(torch.ones(8)))
# prints:
tensor([1065353216, 1065353216, 1065353216, 1065353216, 1065353216, 1065353216,
        1065353216, 1065353216], dtype=torch.int32)
tensor([1., 1., 1., 1., 1., 1., 1., 1.])
```

The root cause is that:

(1) When we get a graph where an output directly aliases an input (in this case), AOTAutograd needs to manually regenerate the output view at runtime in order to appease the autograd engine

(2) AOTAutograd does this by making an attempt to re-run the same set of views through the autograd engine's view-replay tracking, but when that fails it falls back to running `as_strided()` (code: https://github.com/pytorch/pytorch/blob/main/torch/_functorch/aot_autograd.py#L669)

`as_strided()` isn't actually sufficient in this case: our inputs and outputs have different dtypes, but `as_strided()` does not perform cross-dtype views. The same is actually true for other metadata changes like e.g.`view_as_real`/`view_as_complex`, which AOTAutograd manually handles.

This is a case that would be fixed automatically if AOTAutograd carefully tracked all view-chains that it saw (which would also improve perf, as per this internal issue: https://fb.workplace.com/groups/147416452503510/posts/1211736186131257/).

That will take a decent amount work though. A simpler fix would be to manually check if the dtypes of the input and output are different before running the `.as_strided()`, and doing the bitcast view manually when that happens.

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @wconstab @anijain2305
Allow reductions to write into pinned memory
Labels: module: cuda, module: memory usage, triaged, needs research, module: reductions

### 🚀 The feature, motivation and pitch

Reduction operations that have small output, like `tensor.max` and `tensor.min`, ought to allow the output to be in pinned host memory if the input is in GPU.

This improves performance of `x.max().item()` by 5-7x.

### Alternatives

One alternative is to just live with it.  The current way is to just let the output be on the GPU and then copy it from GPU to CPU.  That uses a memcpy, even for a tiny tensor of 4 bytes, and it's wildly slow.

Another alternative is to write your own pybind function that is basically just like the pytorch one except without the error message.

Another option is to, instead of using `copy_` to bring the data from the GPU to CPU, make a function to replace `copy_` that can notice that the data to copy is so tiny that it would be faster to launch and kernel and do the copy to pinned memory than it would be to do a memcpyasync.

### Additional context

```python
a = torch.randn(1,3, device="cuda")
output = torch.empty([1], dtype=a.dtype, pin_memory=True)
torch.max(a, out=output)
```

The error is:

```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: Expected self.device() == out.device() to be true, but got false.  (Could this error message be improved?  If so, please report an enhancement request to PyTorch.)
```

Here is the profiler output:

![image](https://github.com/pytorch/pytorch/assets/69258779/e20daeea-e418-4134-876d-2ced8d8d3ade)

We see that it's spending *most* of the time just copying 4 bytes from GPU to CPU.  In my testing using cub directly, you don't have to wait for the copy, you just need the synchronization and it's super fast, like 5-7x.

You might even consider making pinned memory the default for reductions!  It's really fast.

cc @ptrblck
wip
Labels: module: dynamo, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* (to be filled)



cc @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
GPT2ForSequenceClassification fails accuracy in cpu inference after HF version upgrade
Labels: module: cpu, triaged, oncall: pt2

After upgrading the HF version used in CI (https://github.com/pytorch/pytorch/pull/107400), we see `fail_accuracy` for `GPT2ForSequenceClassification` when running cpu test, https://github.com/pytorch/pytorch/actions/runs/6133028313/job/16644698906


cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @ezyang @msaroufim @wconstab @bdhirsh @anijain2305
Enable bugbear B023 lint
Labels: triaged, open source, topic: not user facing, module: dynamo, ciflow/inductor

Fixes #106571 


cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
torch.sparse_coo_tensor argname quirks + [feature request] `.numpy()`/`from_numpy` method for sparse_coo_tensor/sparse_csr_tensor (or maybe name them as `.scipy()`/`.from_scipy()` or at least under some `torch.utils.*` namespace
Labels: module: sparse, triaged, module: scipy compatibility

### 🐛 Describe the bug

`torch.sparse_coo_tensor(indices, values, size=None)` but in SciPy `scipy.sparse.coo_array((data, (i, j)), [shape=(M, N)])`

Note that vals/indices order is flipped + PyTorch uses `size` instead of `shape`. There are similar quirks for `torch.sparse_csr_tensor`.

I would suggest that PyTorch also has alias argname `shape=` for `size=`, as it matches more with NumPy/SciPy, e.g. https://numpy.org/doc/stable/reference/generated/numpy.zeros.html vs https://pytorch.org/docs/stable/generated/torch.zeros.html (the argname `size=` is likely the remnant of LuaTorch, but now `.shape` has mostly replaced `.size()`)

It would also be great if `.numpy()` turned a PyTorch csr tensor into a scipy one. So maybe a `.scipy()` could be better used, but I don't see it very confusing if we abuse the more standard `.numpy()` for this case as well

Currently (also note the super-strange error for csr):
```python
torch.zeros(123).to_sparse_coo().numpy()
# TypeError: can't convert Sparse layout tensor to numpy. Use Tensor.dense() first.

torch.zeros(123).to_sparse_csr().numpy()
# RuntimeError: expand(torch.LongTensor{[1, 123]}, size=[123]): the number of sizes provided (1) must be greater or equal to the number of dimensions in the tensor (2)
```


cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer
pr build failures in inductor dynamic shape test for operation tests with simple tensors. Side effect of current test framework
Labels: triaged, oncall: pt2, module: dynamic shapes, module: cpu inductor

### 🐛 Describe the bug

As follow on from pull request [https://github.com/pytorch/pytorch/pull/108513]( https://github.com/pytorch/pytorch/pull/108513).

Some tests were created with tensors with a single operand  like `torch.tensor([128]` This tests fail in dynamic tests. I have left the tests commented out as per the pull request and created tests that pass. 

This issue is tracking the problem that dynamic shape tests fail for some tests. The code fails as it expects a loop when there is not one.



### Versions

Collecting environment information...
PyTorch version: 2.1.0a0+gite68b3ad
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.5.1 (arm64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: version 3.26.4
Libc version: N/A

Python version: 3.10.12 | packaged by conda-forge | (main, Jun 23 2023, 22:41:52) [Clang 15.0.7 ] (64-bit runtime)
Python platform: macOS-13.5.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Max

Versions of relevant libraries:
[pip3] flake8==6.0.0
[pip3] flake8-bugbear==23.3.23
[pip3] flake8-comprehensions==3.12.0
[pip3] flake8-executable==2.1.3
[pip3] flake8-logging-format==0.9.0
[pip3] flake8-pyi==23.3.1
[pip3] flake8-simplify==0.19.3
[pip3] mypy==1.4.1
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.24.3
[pip3] torch==2.1.0a0+git716c0c8
[pip3] torchgen==0.0.1
[conda] numpy                     1.24.3                   pypi_0    pypi
[conda] torch                     2.1.0a0+git716c0c8          pypi_0    pypi
[conda] torchgen                  0.0.1                    pypi_0    pypi

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305
Cannot install torchmetrics - ERROR 403
Labels: high priority, oncall: binaries, triaged

### 🐛 Describe the bug

Torchmetrics wheel seems to have broken permission - https://download.pytorch.org/whl/torchmetrics-1.0.3-py3-none-any.whl 
```
docker run --rm -ti ubuntu:18.04
```
inside the docker
```
apt update && apt install python3.7 python3-pip -y && pip3 install --upgrade pip && \
python3.7 -m pip install pytorch-lightning --extra-index-url=https://download.pytorch.org/whl/cu113/
```
error
```
HTTP error 403 while getting https://download.pytorch.org/whl/torchmetrics-1.0.3-py3-none-any.whl (from https://download.pytorch.org/whl/cu113/torchmetrics/)
```

### Versions

NA

cc @ezyang @gchanan @zou3519 @kadeng @seemethere @malfet
The following will always fail on NixOS
Labels: module: cudnn, triaged, topic: build

https://github.com/pytorch/pytorch/blob/9a492fc27f3f1f0f71ed8b24704430a87a99cec9/torch/utils/collect_env.py#L168

```
❯ ldconfig -p | grep libcudnn | rev | cut -d" " -f1 | rev
ldconfig: Can't open cache file /nix/store/46m4xx889wlhsdj72j38fnlyyvvvvbyb-glibc-2.37-8/etc/ld.so.cache
: No such file or directory
```

I'm guessing this should be able to be overridden by supplying your own CUDNN_LIBRARY environment variable or something along those lines.

I came across this issue when trying to debug why i'm getting the following on a nix system.

```
pip install -r requirements.txt
ERROR: torch-1.12.1+cu116-cp39-cp39-linux_x86_64.whl is not a supported wheel on this platform.
```

cc @csarofeen @ptrblck @xwang233
fix(test): `test_ops::test_out` previous uncaught error
Labels: open source, module: inductor, ciflow/inductor

As explained in https://github.com/pytorch/pytorch/issues/109001
 
TorchDynamo will early exit on the `_case_zero_transform` when encountering an exception, thus returning the original tensor.

This PR fixes this test, thus revealing issues with `torch.compile` with `_refs.isreal` and `_refs.fft.iffthn`

Repro:
```
PYTORCH_TEST_WITH_INDUCTOR=1 python -m pytest test/test_ops.py::TestCommonCUDA -k test_out__refs_fft_ihfftn_cuda_float32 -vv -s
PYTORCH_TEST_WITH_INDUCTOR=1 python -m pytest test/test_ops.py::TestCommonCUDA -k test_out__refs_isreal_cuda_float32 -vv -s
```

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov
fix(test, inductor): use deterministic manual seed
Labels: triaged, open source, topic: not user facing

Workaround: https://github.com/pytorch/pytorch/issues/108990

This seems to be unveiled by https://github.com/pytorch/pytorch/pull/108873 fixing https://github.com/pytorch/pytorch/issues/101939.

As a workaound, we can just use a deterministic seed. 

Edit: relevant tests are currently disabled due to unrelated `complex`+`out=` bug; let's keep it open / fix {symptoms, root cause} for when tests are renabled.
DISABLED test_maml_omniglot_mechanism_make_functional_cpu (__main__.TestExamplesCorrectnessCPU)
Labels: triaged, module: flaky-tests, skipped, oncall: pt2, module: functorch

Platforms: dynamo

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

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


Test file path: `functorch/test_eager_transforms.py`

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @Chillee @samdow @kshitij12345 @janeyx99
DISABLED test_complex_half_reference_testing_pow_cuda_complex32 (__main__.TestCommonCUDA)
Labels: triaged, module: flaky-tests, skipped, module: nvfuser, oncall: pt2

Platforms: inductor

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

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

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


Test file path: `test_ops.py`

cc @kevinstephano @jjsjann123 @ezyang @msaroufim @wconstab @bdhirsh @anijain2305
ZeroTensor (and probably neg/conj) doesn't play well with wrapper tensor subclasses
Labels: triaged, module: __torch_dispatch__, ZeroTensor

From @zou3519. Here's a mimimal repro using a vanilla wrapper subclass, `TwoTensor`.

The below segfaults:
```
import torch
from torch.testing._internal.two_tensor import TwoTensor

x_a = torch.ops.aten._efficientzerotensor([2])
x = TwoTensor(x_a, x_a.clone())

y_a = torch.ones(2)
y = TwoTensor(y_a, y_a.clone())

out = torch.mul(x, y)
```

The issue Richard pointed out is that in the python fallback ([here](https://github.com/pytorch/pytorch/blob/af8b04d5f622ea6e2b07594b73ac741ef7dddefa/aten/src/ATen/core/PythonFallbackKernel.cpp#L51)), we always add the ZeroTensor key to the exclude TLS.

However, we have a tensor subclass that **holds** a zero tensor. So when our subclass's `__torch_dispatch__` tries to redispatch on the inner tensor, we should expect that redispatch to be able to hit the ZeroTensor key. Instead, it doesn't hit the ZeroTensor key, and we end up sending a `ZeroTensor` (which has a null dataptr) directly to the native `mul` kernel in TensorIterator, which segfaults.

The same probably applies to other stuff like the Negative/Conjugate keys.

cc @ezyang @gchanan @zou3519 @kadeng @Chillee @albanD @samdow
feat(inductor): Accumulate fp16 for bmm and mm
Labels: triaged, open source, topic: new features, module: inductor, ciflow/inductor

Fixes https://github.com/pytorch/pytorch/issues/108621

Replace: https://github.com/pytorch/pytorch/pull/108637 due to numerous errors

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov
[feature request] Provide some sparse eigen solver(s) for PyTorch (maybe via `ARPACK` as in scipy) + SPD sparse / laplace linear system solver - maybe NVidia AMGx library?
Labels: module: sparse, triaged, module: linear algebra

**UPD**: please feel free to close this issue if duplicate to the very related https://github.com/pytorch/pytorch/issues/58828

### 🚀 The feature, motivation and pitch

Orignally requested and discussed at:
- https://github.com/pytorch/pytorch/issues/24185
- https://github.com/pytorch/pytorch/issues/24185#issuecomment-1712566862

In practice, the top needed things is actually extremal eigval/eigvec solver, as in https://github.com/pytorch/pytorch/issues/24185

Available functions binding to ARPACK in scipy:
- https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.eigs.html
- https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.eigsh.html

A general description in scipy docs: https://docs.scipy.org/doc/scipy/tutorial/arpack.html
A third-party package for PyTorch: https://github.com/rfeinman/Torch-ARPACK but it would be very nice to have this widely-needed functionality in core. Also, a newer development seems to happen in https://github.com/opencollab/arpack-ng

This types of solvers are needed for many classical computer graphics and computer vision algorithms where smoothing sparse (often some kind of banded) laplacians are formed - but even more importantly in physics/applied maths where this is useful for solving finite elements discretization equations (if i'm not mistaken). In the new neural net world it might be nice to be able to differentiate through these solvers to the features, but at least the non-differentiable bindings to enable smoothing and revival of classical techniques.

Maybe related LinearOperator libraries: 
- https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.LinearOperator.html
- https://pylops.readthedocs.io/en/stable/index.html 
- https://github.com/wilson-labs/cola

Might also be good to have something like this API included in PyTorch. Ideally, this would be supported both for CUDA and batched regimes to enable training.

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer @jianyuh @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano @lezcano @rgommers 

### Alternatives

_No response_

### Additional context

_No response_
About FSDP
Labels: oncall: distributed, triaged

@svenstaro 
I would like to ask why my GPU memory usage will be lower than FSDP mode when I am using DP mode?
model = DP(model)
`model = FSDP(model,auto_wrap_policy=my_auto_wrap_policy,
                        # use_orig_params=True,#是否保留原始参数
                        #  cpu_offload=CPUOffload(offload_params=True),
                        #  mixed_precision=fp16_policy,
                        # sharding_strategy=ShardingStrategy.SHARD_GRAD_OP, # ZeRO 2
                        sharding_strategy=ShardingStrategy.FULL_SHARD, # ZeRO 3
                        backward_prefetch = BackwardPrefetch.BACKWARD_POST, # optimize memory
                        # backward_prefetch = BackwardPrefetch.BACKWARD_PRE, # optimize speed
                        )`

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu
Exporting the operator 'aten::_convolution_mode' to ONNX opset version 14 is not supported.
Labels: module: onnx, triaged, onnx-triaged, onnx-needs-info, release notes: onnx

### 🐛 Describe the bug

```python

import torch
model = darkNet()


torch.onnx.export(model,               # model being run
                  torch.randn(1, 3, 448, 448), # dummy input (required)
                  "DN.onnx",   # where to save the model (can be a file or file-like object)
                  export_params=True)
```

### Versions

.
Dtensor and jacrev
Labels: oncall: distributed, triaged, tensor subclass, module: forward ad, module: functorch, module: dtensor

### 🚀 The feature, motivation and pitch

Hi,Dtensor can slice the tensor to different devices, how can we combine [jacrev](https://pytorch.org/functorch/stable/generated/functorch.jacrev.html) and [vmap](https://pytorch.org/docs/stable/generated/torch.vmap.html#torch.vmap) with the dtensor ,Make a Jacobi matrix can be sliced to different devices or nodes?Then make this Jacobi matrix global computation?Here's an example, but it looks like it can only be accessed via rank.... **I'm not so sure about the dtensor for algebraic operations.**

### Alternatives
```python

@spawn_threads_and_init_comms
def shard_big_tensor(world_size):
  mesh = DeviceMesh("cpu", [0,1,2,3])
  djac = zeros([D,D], device_mesh=mesh,placements=[Shard(0)])
  djac = compute_jac(xp,djac,world_size,dist.get_rank())
  print(f"on rank: {dist.get_rank()}, dtensor global shape: {djac.shape}, local shape: {djac.to_local().shape}")

def predict(weight, bias, x):
    return F.linear(x, weight, bias).tanh()

def compute_jac(xp,djac,world_size,rank):
    for idx in range(int(D/world_size)):
      vec = unit_vectors[idx+(rank)*int(D/world_size)]
      x = torch.autograd.grad(predict(weight, bias, xp), xp, vec)[0]
      djac.to_local()[idx] = torch.autograd.grad(predict(weight, bias, xp), xp, vec)[0]
      jacobian[idx+(rank)*int(D/world_size)] = djac.to_local()[idx]
    return djac

WORLD_SIZE=4
D = 16
x_origin = torch.randn(D)
jacobian = torch.zeros((D,D))
weight =  torch.randn(D, D)
bias =  torch.randn(D)
x = x_origin.clone() # feature vector
xp = x.clone().requires_grad_()
unit_vectors = torch.eye(D)
shard_big_tensor(WORLD_SIZE)

from torch.func import jacrev
ft_jacobian = jacrev(predict, argnums=2)(weight, bias, x)
assert torch.allclose(ft_jacobian, jacobian)
### Additional context
on rank: 1, dtensor global shape: torch.Size([16, 16]), local shape: torch.Size([4, 16])
on rank: 0, dtensor global shape: torch.Size([16, 16]), local shape: torch.Size([4, 16])
on rank: 2, dtensor global shape: torch.Size([16, 16]), local shape: torch.Size([4, 16])
on rank: 3, dtensor global shape: torch.Size([16, 16]), local shape: torch.Size([4, 16])

```[tasklist]
### Tasks
colab:https://colab.research.google.com/drive/1UqUCEfJDhNDPvZZjDQuOdmxepkqGhaQz?usp=sharing
```


cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @ezyang @msaroufim @albanD @zou3519 @Chillee @samdow @kshitij12345 @janeyx99
Really slow compilation times for torch.compile causing distributed training errors
Labels: triaged, module: ddp, oncall: pt2

### 🐛 Describe the bug

We are seeing issues where `torch.compile` takes a very long time (17mins - 30 mins) to compile models despite a warm cache and results in distributed training errors like NCCL timeouts since the jobs don't make progress. A couple of examples of slow compilation are follows: https://gist.github.com/pritamdamania87/a40cbad2ec15961beb16639ddb29af9c and https://gist.github.com/pritamdamania87/c5c9031347cfb57098360ce9f93b479e.

Also, this is not the first compile where we see such slow times. `TORCHINDUCTOR_CACHE_DIR` and `TRITON_CACHE_DIR` is set and the cache was populated during the first run of the training job. The second run of job still sees slow compilation times despite also setting `torch._inductor.config.compile_threads = 16`.

Would be great to know how to debug why the compilation times are so slow and how to speed this up.

### Error logs

_No response_

### Minified repro

_No response_

### Versions

PyTorch 2.0.1

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305
Unnecessary cuda synchronizations that we should remove in PyTorch
Labels: module: performance, module: cuda, triaged

### 🚀 The feature, motivation and pitch

There are a number of unnecessary cuda synchronizations in PyTorch ops, and I think we should endeavor to remove them whenever possible.
To check syncs, you can use `torch.cuda.set_sync_debug_mode("warn")`

I'm creating this issue to track ones that I've seen/found.

1. torch.multinomial with `num_samples=1`. For this I think we should simply remove the error check causing the sync, and ideally turn it into a cuda async error. https://github.com/pytorch/pytorch/blob/main/aten/src/ATen/native/Distributions.cpp#L615
```
A = torch.rand(10)
torch.multinomial(A, num_samples=1)
```

2. repeat_interleave with a tensor number of repeats encourages synchronization. We cannot use `repeats` with a non-cuda tensor, and that forces a synchronization. For this I think we should add a list of ints overload or allow passing a CPU tensor for repeats.
```
A = torch.randn(3, device='cuda')
num_repeats = torch.tensor([2, 3, 5])
out = torch.repeat_interleave(A, num_repeats.cuda(), dim=0)
```


3. Indexing with a scalar tensor performs a synchronization. See https://github.com/pytorch/pytorch/issues/105641 for more details.

4. `torch.normal` also incurs a sync on std: https://github.com/pytorch/pytorch/blob/main/aten/src/ATen/native/DistributionTemplates.h#L222

5. `nanmedian` incurs a sync: https://github.com/pytorch/pytorch/blob/main/aten/src/ATen/native/cuda/Sorting.cpp#L149



### Alternatives

_No response_

### Additional context

_No response_

cc @ptrblck
torch.compile graph breaks should be independent of DDP buckets
Labels: triaged, module: ddp, oncall: pt2

### 🐛 Describe the bug

Creating this issue to follow up on the discussion here: https://github.com/pytorch/pytorch/issues/108269#issuecomment-1708968063. As described [here](https://dev-discuss.pytorch.org/t/torchdynamo-update-9-making-ddp-work-with-torchdynamo/860) DDPOptimizer inserts graph buckets at DDP bucket boundaries when torch.compile and DDP are used together.

This tightly couples torch.compile graph breaks with DDP bucketing strategy (which should be completely orthogonal) and results in suboptimal performance. Concretely, this doesn't allow us to tune DDP bucket size appropriately. If you reduce the DDP bucket size, you potentially get better compute-communication overlap however this results in more graph breaks regressing compute performance. If you increase DDP bucket size this removes graphs breaks and gives better compute performance, however this results in a regression in compute-communication overlap.

Ideally, we would like to keep one constant (graph breaks) and tune the other (DDP bucket size) or vice-versa.

### Error logs

_No response_

### Minified repro

_No response_

### Versions

main branch

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305
Dynamo's eval_frame.c is not thread/subinterpreter safe
Labels: triaged, module: multithreading, oncall: pt2, module: dynamo

### 🐛 Describe the bug

In `eval_frame.c`, the following are not thread/subinterpreters safe:

There are a bunch of static non-const non-threadlocal global variables that are shared. These should be moved to the module state and the module should, in the long run, support [multi-phase initialization](https://docs.python.org/3/c-api/module.html#multi-phase-initialization) https://github.com/pytorch/pytorch/blob/0f88d93b10fbe715afa7affb7ee0a3da90f406cd/torch/csrc/dynamo/eval_frame.c#L180
https://github.com/pytorch/pytorch/blob/0f88d93b10fbe715afa7affb7ee0a3da90f406cd/torch/csrc/dynamo/eval_frame.c#L1021

Subinterpreters are coming in 3.12/ 3.13 (see https://peps.python.org/pep-0684/ and  https://peps.python.org/pep-0554/). This is an opt-in thing and we might want to support that use case. 

There's a CPython guide on the steps to isolate a module https://peps.python.org/pep-0630/#module-state-access-from-regular-methods.

Note: this does not make the module nogil safe. That can be done later.

### Error logs

_No response_

### Minified repro

_No response_

### Versions

main

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
cuda.cmake: Found Conflicting, Identical CUDA Install
Labels: module: build, module: cuda, triaged

### 🐛 Describe the bug

Hi,

I am compiling pytorch 2.1.0-rc3 from source on RHEL8 using the PPC64LE CPU architecture and CUDA support (7.0 for V100).

During compilation, somehow the following configure error occurs:
```
CMake Error at cmake/public/cuda.cmake:65 (message):
  Found two conflicting CUDA installs:

  V12.0.76 in '/usr/tce/packages/cuda/cuda-12.0.0/include' and

  V12.0.76 in '/usr/tce/packages/cuda/cuda-12.0.0/nvidia/include'
Call Stack (most recent call first):
  cmake/Dependencies.cmake:44 (include)
  CMakeLists.txt:722 (include)
```

Should this error be skipped if the same version is identified?
https://github.com/pytorch/pytorch/blob/v2.1.0-rc3/cmake/public/cuda.cmake#L63-L68

### Versions

- pytorch 2.1.0-rc3
- CUDA 12.0.76
- Clang 12.0.1
- RHEL 8.7

cc @malfet @seemethere @ptrblck
DISABLED test_nondeterministic_alert_MaxUnpool1d_cuda_float32 (__main__.TestTorchDeviceTypeCUDA)
Labels: module: tests, triaged, module: flaky-tests, skipped, oncall: pt2

Platforms: inductor

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

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

cc @mruberry @ezyang @msaroufim @wconstab @bdhirsh @anijain2305
[c10d] fix functional collective reduce op naming convention
Labels: oncall: distributed, triaged, module: c10d

see discussions in https://github.com/pytorch/pytorch/pull/108758#pullrequestreview-1615186895

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu
[dynamo] Missing guard on global function
Labels: triaged, oncall: pt2, module: dynamo, module: guards

### 🐛 Describe the bug

```python
import torch

def some_fn(x):
    return torch.sin(x) + 20

def foo(x, y):
    x = some_fn(x)

    def add(x, y):
        return x + y

    return add(x, y)

x = torch.ones(1,)
y = torch.ones(1,)

opt = torch.compile(foo, fullgraph=True, backend='aot_eager')
print("ACTUAL:", opt(x, y), " EXPECTED:", foo(x, y))

# Change some_fn
some_fn = lambda x: torch.cos(x)

print("ACTUAL:", opt(x, y), " EXPECTED:", foo(x, y))
```

Output
```
ACTUAL: tensor([21.8415])  EXPECTED: tensor([21.8415])
ACTUAL: tensor([21.8415])  EXPECTED: tensor([1.5403])
```

Output: `TORCH_LOGS="+guards" python test.py` (no guards for `some_fn`)
```
[2023-09-08 20:33:41,833] [0/0] torch._dynamo.guards.__guards: [DEBUG] GUARDS:
[2023-09-08 20:33:41,834] [0/0] torch._dynamo.guards.__guards: [DEBUG] hasattr(L['x'], '_dynamo_dynamic_indices') == False           # _dynamo/variables/builder.py:1273 in wrap_fx_proxy_cls
[2023-09-08 20:33:41,834] [0/0] torch._dynamo.guards.__guards: [DEBUG] hasattr(L['y'], '_dynamo_dynamic_indices') == False           # _dynamo/variables/builder.py:1273 in wrap_fx_proxy_cls
[2023-09-08 20:33:41,834] [0/0] torch._dynamo.guards.__guards: [DEBUG] ___is_grad_enabled()                                          # _dynamo/output_graph.py:359 in init_ambient_guards
[2023-09-08 20:33:41,834] [0/0] torch._dynamo.guards.__guards: [DEBUG] not ___are_deterministic_algorithms_enabled()                 # _dynamo/output_graph.py:355 in init_ambient_guards
[2023-09-08 20:33:41,834] [0/0] torch._dynamo.guards.__guards: [DEBUG] ___is_torch_function_enabled()                                # _dynamo/output_graph.py:363 in init_ambient_guards
[2023-09-08 20:33:41,834] [0/0] torch._dynamo.guards.__guards: [DEBUG] utils_device.CURRENT_DEVICE == None                           # _dynamo/output_graph.py:361 in init_ambient_guards
[2023-09-08 20:33:41,834] [0/0] torch._dynamo.guards.__guards: [DEBUG] check_tensor(L['x'], Tensor, DispatchKeySet(CPU, BackendSelect, ADInplaceOrView, AutogradCPU), torch.float32, device=None, requires_grad=False, size=[1], stride=[1])  # _dynamo/variables/builder.py:1273 in wrap_fx_proxy_cls
[2023-09-08 20:33:41,834] [0/0] torch._dynamo.guards.__guards: [DEBUG] check_tensor(L['y'], Tensor, DispatchKeySet(CPU, BackendSelect, ADInplaceOrView, AutogradCPU), torch.float32, device=None, requires_grad=False, size=[1], stride=[1])  # _dynamo/variables/builder.py:1273 in wrap_fx_proxy_cls
ACTUAL: tensor([21.8415])  EXPECTED: tensor([21.8415])
ACTUAL: tensor([21.8415])  EXPECTED: tensor([1.5403])
```

cc: @zou3519

### Versions

main

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
Run CI for oneDNN Graph Inductor Integration
Labels: module: cpu, module: mkldnn, open source, release notes: quantization, module: inductor, ciflow/inductor

cc @jgong5 @mingfeima @XiaobingSuper @ashokei @jingxu10 @gujinghui @PenghuiCheng @jianyuh @min-jean-cho @yanbing-j @Guobing-Chen @Xia-Weiwen @voznesenskym @penguinwu @EikanWang @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov
RuntimeError: Unrecognized tensor type ID: ZeroTensor
Labels: triaged, ZeroTensor

### 🐛 Describe the bug

I am using the nightly build for pytorch compatible with CUDA 12.1 and run into `message: RuntimeError: Unrecognized tensor type ID: ZeroTensor`. I use to build a python wheel that I then use in with pytorch==1.13.0. Is the issue due to change in pytorch versions?

I dont see any information corresponding to this error on the web.

### Versions

Using torch=2.0.1 with cuda12.1
[dynamo] fix functools.wraps on nested functions
Labels: triaged, open source, module: dynamo, ciflow/inductor, release notes: dynamo

Fixes https://github.com/pytorch/pytorch/issues/103913


cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
nanogpt_generate and clip pass regression
Labels: triaged, module: inductor

### 🐛 Describe the bug

These models regressed from 9/01 -> 9/02. Filing this issue to track / further triage.

https://hud.pytorch.org/benchmark/blueberries/inductor_no_cudagraphs?startTime=Fri,%2001%20Sep%202023%2018:26:13%20GMT&stopTime=Fri,%2008%20Sep%202023%2018:26:13%20GMT&granularity=hour&mode=inference&dtype=bfloat16&lBranch=main&lCommit=ffc0c46092efef1f3b51becc8f5770abcec5c23a&rBranch=main&rCommit=591cb776af68e43f41cba1a29b6219341b75d951



### Versions

master

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov
Inconsistent any( ) between cuda and cpu - Incorrect complex to bool conversion
Labels: triaged, module: complex, module: correctness (silent)

### 🐛 Describe the bug

Currently, casting to bool is not consistent with numpy or default python complex numbers. Although the c10::Complex bool operator does follow numpy, the copy kernel discards the imaginary part and is incorrectly evaluating to false positions where the imaginary part was not zero. A side effect of this, is inconsistent behaviour of the any( ) operator between cuda and cpu, due to cuda using static_cast to bool and cpu using the copy kernel before the operation. A possible straightforward solution is to specialize static_cast_with_inter_type in c10/util/TypeCast.h for complex to bool conversion to ensure that the cast is always correct. 

# code to reproduce the issue:
```
import torch
x = torch.full((3,3,3),0+1j)
print ( x.any(-1) )
print( x.cuda().any(-1))
```
![image](https://github.com/pytorch/pytorch/assets/93442086/72a0c153-000a-4344-b746-68976e9941be)


### Versions

cuda: 11.8 
python: 3.10
torch : 2.0.1+cu118

cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved