gopikrsmscs/torch-issues huggingface dataset:
`torch.linalg.lstsq` Trigger RuntimeError under UndefinedBehaviorSanitizer
Labels: triaged, module: linear algebra, actionable, module: sanitizers, module: edge cases

### 🐛 Describe the bug

The implementation of `torch.linalg.lstsq` contains undefined behavior caught by UB sanitizer. Without sanitizers, the test terminates normally.
Test:
```python
import torch

def test():
    arg_1 = torch.rand([2, 3, 5, 5, 0], dtype=torch.float64).clone()
    arg_2 = torch.rand([2, 3, 5, 5], dtype=torch.float64).clone()
    res = torch.linalg.lstsq(arg_1,arg_2,)

test()
```
Error log:
```
pytorch/c10/core/TensorImpl.h:1521:38: runtime error: applying non-zero offset 40 to null pointer
``` 

### Versions

```
PyTorch version: 1.14.0a0+git6e5f736
Is debug build: False
CUDA used to build PyTorch: Could not collect
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: 11.1.0-6
CMake version: version 3.22.1
Libc version: glibc-2.35

Python version: 3.9.12 (main, Apr  5 2022, 06:56:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.15.0-52-generic-x86_64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: 11.8.89
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: 
GPU 0: NVIDIA GeForce RTX 3090
GPU 1: NVIDIA GeForce RTX 3090
GPU 2: NVIDIA GeForce RTX 3090

Nvidia driver version: 515.65.01
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.4.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.5
[pip3] numpydoc==1.2
[pip3] torch==1.14.0a0+git6e5f736
[conda] blas                      1.0                         mkl  
[conda] cudatoolkit               11.3.1               h2bc3f7f_2  
[conda] mkl                       2021.4.0           h06a4308_640  
[conda] mkl-service               2.4.0            py39h7f8727e_0  
[conda] mkl_fft                   1.3.1            py39hd3c417c_0  
[conda] mkl_random                1.2.2            py39h51133e4_0  
[conda] numpy                     1.21.5           py39he7a7128_1  
[conda] numpy-base                1.21.5           py39hf524024_1  
[conda] numpydoc                  1.2                pyhd3eb1b0_0  
[conda] torch                     1.14.0a0+git6e5f736          pypi_0    pypi
```

cc @ezyang @gchanan @zou3519 @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
INTERNAL ASSERT FAILED. Missing scalar type infromation.
Labels: triaged, module: nvfuser

### 🐛 Describe the bug

Hi, I'm trying to run [DiffDock](https://github.com/gcorso/diffdock) and I get the following error:

```tensor_type->scalarType().has_value() INTERNAL ASSERT FAILED at "/opt/conda/conda-bld/pytorch_1659484809662/work/torch/csrc/jit/codegen/cuda/type_promotion.cpp":111, please report a bug to PyTorch. Missing Scalar Type information```

I'm not able to share a minimal example as I don't know where the error arises from. Do you have any idea how to investigate this? How do I get a traceback?

### Versions

Collecting environment information...
PyTorch version: 1.12.1
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.31

Python version: 3.9.13 (main, Oct 13 2022, 21:15:33)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-4.18.0-305.10.2.el8_4.x86_64-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to:
GPU models and configuration: GPU 0: NVIDIA A100-SXM4-40GB
Nvidia driver version: 470.57.02
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.1
[pip3] torch==1.12.1
[pip3] torch-cluster==1.6.0
[pip3] torch-geometric==2.1.0.post1
[pip3] torch-scatter==2.0.9
[pip3] torch-sparse==0.6.15
[pip3] torch-spline-conv==1.2.1
[pip3] torchaudio==0.12.1
[pip3] torchvision==0.13.1
[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            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.23.1           py39h6c91a56_0
[conda] numpy-base                1.23.1           py39ha15fc14_0
[conda] pyg                       2.1.0           py39_torch_1.12.0_cu113    pyg
[conda] pytorch                   1.12.1          py3.9_cuda11.3_cudnn8.3.2_0    pytorch
[conda] pytorch-cluster           1.6.0           py39_torch_1.12.0_cu113    pyg
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] pytorch-scatter           2.0.9           py39_torch_1.12.0_cu113    pyg
[conda] pytorch-sparse            0.6.15          py39_torch_1.12.0_cu113    pyg
[conda] pytorch-spline-conv       1.2.1           py39_torch_1.12.0_cu113    pyg
[conda] torchaudio                0.12.1               py39_cu113    pytorch
[conda] torchvision               0.13.1               py39_cu113    pytorch

cc @kevinstephano @jjsjann123
torchdynamo is not properly setting up input tracking (e.g., for symbolic shape guards) for view bases
Labels: triaged, bug, oncall: pt2

### 🐛 Describe the bug

When we convert a real tensor to a fake tensor, if the original tensor was a differentiable view we will also convert its base to a fake tensor, so we can construct a fake tensor that also looks like a view. In dynamic shapes, this means that we will allocate symbolic sizes for both the base as well as the view, and it turned out that in some circumstances we could end up producing guards on the base! This is problematic, because dynamo only considers the view as a new tensor inputs and only tracks its symints. The assert that fails is typically:

```
        assert expr_found, f"Failed to find {expr}"
```

in DynamoGuardPrinter in this case.

In [92ef26b96bf0c36e4b8ad87dc0419f46dfc65c69](https://github.com/pytorch/pytorch/pull/84246/commits/92ef26b96bf0c36e4b8ad87dc0419f46dfc65c69) we make this problem less likely to occur by suppressing guards that occur when creating fake tensors, since the naughty guard we observed in practice was caused by the `as_strided` call we use to setup the view performing a bounds check. But it would be better to fix this properly, especially since we still have "failed to find sX" in our tests.

The general idea is that whenever we allocate symbolic integers for a tensor, we should ALWAYS set it up in the environment. However, it is difficult to tell how many inputs a tensor will actually be (there is not only the _base field, but also the grad field); so it may be easiest if fake tensor converter communicates this information via a callback that has also says the attribute path, so we can make an appropriate source for the tensor.

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh @voznesenskym 

### Error logs

_No response_

### Minified repro

_No response_
MPS test_numpy_ref_mps_nn_functional_group_norm_mps_float32 is flaky?
Labels: triaged, module: flaky-tests, module: mps

### 🐛 Describe the bug

https://github.com/pytorch/pytorch/actions/runs/3446932166/jobs/5752655448

### Versions

master

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
[dynamo+ddp+symbolic-shapes] Issue Tracker
Labels: triaged, oncall: pt2

we should support these systems working togehter.  i think they should compose, but it requires some testing.

- [ ] huggingface accelerate nlp_model crashes ([repro cmd](https://gist.github.com/wconstab/12ce82ceded7a3ee4748b24cc5ec502e#file-repro-instructions), [log](https://gist.github.com/wconstab/12ce82ceded7a3ee4748b24cc5ec502e#file-symbolic_nlp_example-log))
- [ ] torchbench hf_Bert is slow with symbolic-shapes (`python benchmarks/dynamo/distributed.py --torchbench_model hf_Bert --ddp --dynamo inductor` on symbolic-shapes branch)

cc @ezyang @soumith @msaroufim @ngimel @bdhirsh
Investigate why `test_aot_autograd_symbolic_exhaustive_masked_median_cpu_float32` is flaky
Labels: triaged, module: flaky-tests

### 🐛 Describe the bug

This failed on trunk, but I couldn't reproduce locally on Linux/M1:

```
test_aot_autograd_symbolic_exhaustive_masked_median_cpu_float32 (__main__.TestEagerFusionOpInfoCPU) ... unexpected success (2.010s)
```

For me, it just xfailed as it should. Added a skip for now.

Perhaps related to sample inputs? It has some nan handling in the implementation, but that's just a guess.

Reference: https://github.com/pytorch/pytorch/pull/88776

### Versions

https://github.com/pytorch/pytorch/pull/88776
Add alphatensor support for faster matrix multiplication?
Labels: feature, triaged, matrix multiplication

### 🚀 The feature, motivation and pitch

I didn't find any proposal or issue about it.
In short alphatensor is a way to find a new faster algorithms for matrix multiplication operations. 
It even have a functionality to find the best algorithm adapted to particular hardware.
It makes sense to add support for it in some way or another, becuase almost 100% of running models on pytorch
is extensively using matrix multiplication operations.
See - [alphatensor](https://github.com/deepmind/alphatensor)

cc @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
[Inductor] Input Buffers Should Be Representable As Storage And Layout
Labels: triaged, oncall: pt2

### 🐛 Describe the bug

[InputBuffer](https://github.com/pytorch/pytorch/blob/master/torch/_inductor/ir.py#L1897)'s currently do not have an associated storage. This prevents correct handling of aliased inputs - see [TODO here](https://github.com/pytorch/pytorch/blob/master/torch/_inductor/graph.py#L202). 

When calling [require_stride_order](https://github.com/pytorch/pytorch/blob/master/torch/_inductor/ir.py#L2465), because `is_storage_and_layout` returns False for InputBuffers we fall through to an unnecessary copy. 


A shorter term fix would be to handle InputBuffers in `require_stride_order`.

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
Inductor may merge two output tensors into one
Labels: triaged, module: inductor

### 🐛 Describe the bug

Consider the following example:
```python
import torch._dynamo
import logging

def g(a):
    b = a * 2
    c = a * 2
    return b, c

x = torch.rand((1000000,), device="cuda", requires_grad=True)
expect = g(x)
actual = torch._dynamo.optimize("inductor")(g)(x)
assert expect[0] is not expect[1]
assert actual[0] is actual[1]
```

The outputs have been merged into a single tensor, so downstream users of this function may get silently wrong results if `a` or `b` are mutated.

### Versions

```
PyTorch version: 1.14.0a0+git034872d
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (conda-forge gcc 9.5.0-17) 9.5.0
Clang version: Could not collect
CMake version: version 3.24.1

Python version: 3.8 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: NVIDIA GeForce RTX 2060
GPU 1: NVIDIA GeForce RTX 2060

Nvidia driver version: 515.65.01
cuDNN version: Probably one of the following:
/usr/local/cuda-11.7.1/targets/x86_64-linux/lib/libcudnn.so.8
/usr/local/cuda-11.7.1/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8
/usr/local/cuda-11.7.1/targets/x86_64-linux/lib/libcudnn_adv_train.so.8
/usr/local/cuda-11.7.1/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8
/usr/local/cuda-11.7.1/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8
/usr/local/cuda-11.7.1/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8
/usr/local/cuda-11.7.1/targets/x86_64-linux/lib/libcudnn_ops_train.so.8
HIP runtime version: N/A
MIOpen runtime version: N/A
```

cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire
Return the attention weights using the Transformer Encoder class. 
Labels: triaged, oncall: transformer/mha

### 🚀 The feature, motivation and pitch

Hey, when using the Transformer Encoder class it would be nice to have ```need_weights``` as an additional variable that can be passed down to ```F.multi_head_attention_forward ```. Right now the feature of returning the attention weights is as far as my understanding goes not accessible from the Transformer class since ```need_weights``` is manually set to false. It would be great if this was possible since one could very easily compute the attention rollout. 


### Alternatives

_No response_

### Additional context

_No response_

cc @jbschlosser @bhosmer @cpuhrsch @erichan1
[feature request] Get/set fastmath CPU bit (and some other FPU flags?)
Labels: module: numerical-stability, module: cpu, triaged

### 🚀 The feature, motivation and pitch

Originally proposed at: https://github.com/pytorch/pytorch/issues/81690#issuecomment-1309911123

Loading third-party libraries may affect CPU fpu bits such as denormals mode and fastmath (also affecting CPU reproducibility, see https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html). It's useful to be able to detect and reset these bits directly from PyTorch API. Currently there only exists `torch.set_flush_denormal`. There is no `get_flush_denormal`.

It would be useful to have extensive set of functions for getting/setting these CPU flags (FTZ/DAZ?). It may also be good for having a single function for getting/setting all such flags. Then it'd be easy to dump to a file all flags and then recover them in one go and also provide end-user visibility into this age-old concern.

### Alternatives

_No response_

### Additional context

_No response_

cc @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
ImportError: libcupti.so.11.2: cannot open shared object file: No such file or directory
Labels: module: build, module: cuda, triaged

### 🐛 Describe the bug

---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
      4 import random
      5 import copy
----> 6 import torch
      7 #import learn2learn as l2l
      8 import numpy as np

File /dev_data_1/conda/envs/meta/lib/python3.8/site-packages/torch/__init__.py:202, in <module>
    200     if USE_GLOBAL_DEPS:
    201         _load_global_deps()
--> 202     from torch._C import *  # noqa: F403
    204 # Appease the type checker; ordinarily this binding is inserted by the
    205 # torch._C module initialization code in C
    206 if TYPE_CHECKING:

ImportError: libcupti.so.11.2: cannot open shared object file: No such file or directory

### Versions

torch 1.12.0
python 3.8.13

cc @malfet @seemethere @ngimel
Potential bug in torch.optim.lr_scheduler.CosineAnnealingWarmRestarts
Labels: triaged, actionable, module: LrScheduler

https://github.com/pytorch/pytorch/blob/fb5c6ae61f1f622ec388ae9fa00e7683ce1729ce/torch/optim/lr_scheduler.py#L1407

Should be self.T_cur = self.T_cur % self.T_i, not self.T_cur = self.T_cur - self.T_i.
Batched Random Number Generators
Labels: triaged, module: random

### 🚀 The feature, motivation and pitch

Hello there,

The vast majority of PyTorch methods support batched inputs and outputs. However, the random generators are left behind in this regard! This is particularly important for applications were most of the heavy-lifting comes from training many identically-shaped models independently and simultaneously in a batched manner.

I understand that one can sample batched random tensors from a single generator. That being said, you cannot reproduce each slice without reproducing the entire tensor.  

There are many applications which could benefit from training many reproducible configurations in a batch-wise manner. For example, take few-shot learning evaluations where most settings deal with 1-layer classifiers but tens of thousands of independent episodes and classifiers. You can create your own batched layers and modules from scratch using batched matrix multiplications and so on, but a truly batched RNG is still unavailable.

### Alternatives

For now, I've written my own "fake" batch RNG shell, where I create many generators in a list and seed them manually. Upon random generation requests, the shell has to call each generator, and stack the resulting random samples. This is of course very inefficient. To improve the time efficiency of this approach, I defined random number caches, in order to reduce the number of calls to the generators. This induces an almost unnecessary memory-computation trade-off, and still loses to a truly efficient batched RNG. The GPU memory also limits the caching benefits.

### Additional context

_No response_

cc @pbelevich
torch.jit.trace() - AttributeError: 'NoneType' object has no attribute '__module__
Labels: oncall: jit

### 🐛 Describe the bug

The examples in the following tutorials:
https://pytorch.org/docs/stable/generated/torch.jit.trace.html (the second example)
https://pytorch.org/tutorials/beginner/Intro_to_TorchScript_tutorial.html (examples starting from Tracing Modules)

raise the error ``` AttributeError: 'NoneType' object has no attribute '__module__'``` in the code line ``` torch.jit.trace() ```

### Versions

```
PyTorch version: 1.13.0+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 10 Enterprise
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: N/A

Python version: 3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.19044-SP0
Is CUDA available: True
CUDA runtime version: 11.7.99
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3060
Nvidia driver version: 517.40
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.4
[pip3] pytorch-lightning==1.7.7
[pip3] torch==1.13.0+cu117
[pip3] torch-model-archiver==0.6.0
[pip3] torch-workflow-archiver==0.2.4
[pip3] torchaudio==0.13.0+cu117
[pip3] torchmetrics==0.10.0
[pip3] torchserve==0.6.0
[pip3] torchvision==0.14.0+cu117
[conda] Could not collect
```

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
RuntimeError: method '__torch__.___torch_mangle_0.MyModule.sin' already defined.
Labels: oncall: package/deploy

### 🐛 Describe the bug

The following program runs into the following error. It appears that the script and trace somehow collide on their use of the global compilation unit? Adding `_compilation_unit=torch._C.CompilationUnit()` doesn't seem to help though.

```python
import torch


class MyModule(torch.nn.Module):
    @torch.jit.export
    def sin(self, x):
        return torch.ops.aten.sin(x)

module = MyModule()
example_input = torch.ones(2, 3)
torch.jit.script(module)
torch.jit.trace_module(module, {"sin": example_input})
```

```
Traceback (most recent call last):
  File "/tmp/repro2.py", line 12, in <module>
    torch.jit.trace_module(module, {"sin": example_input})
  File "/usr/local/google/home/silvasean/.local/lib/python3.10/site-packages/torch/jit/_trace.py", line 1049, in trace_module
    module._c._create_method_from_trace(
RuntimeError: method '__torch__.___torch_mangle_0.MyModule.sin' already defined.
```

### Versions

Collecting environment information...
PyTorch version: 1.14.0.dev20221028+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux rodete (x86_64)
GCC version: (Debian 12.2.0-3) 12.2.0
Clang version: 14.0.6-2
CMake version: version 3.24.1
Libc version: glibc-2.35

Python version: 3.10.7 (main, Sep  8 2022, 14:34:29) [GCC 12.2.0] (64-bit runtime)
Python platform: Linux-5.18.16-1rodete1-amd64-x86_64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.3
[pip3] torch==1.14.0.dev20221028+cpu
[pip3] torchvision==0.15.0.dev20221028+cpu
[conda] Could not collect
scatter_ op convert onnx exception
Labels: module: onnx, triaged, onnx-needs-info

### 🐛 Describe the bug

```python
input_char = torch.LongTensor(batch_size).fill_(0).to(device) 
def _char_to_onehot(self, input_char, onehot_dim=38):
        input_char = input_char.unsqueeze(1)
        batch_size = input_char.size(0)
        one_hot = torch.FloatTensor(batch_size, onehot_dim).zero_().to(device)
        one_hot = one_hot.scatter_(1, input_char, 1)
        return one_hot
```

when scatter_ op convert to onnx,,it can convert success,but then run onnx with onnxruntime.InferenceSession(ModelPath)

errors:
failed:Type Error: Type parameter (T) bound to different types (tensor(float) and tensor(int64) in node (ScatterElements_53).

why it hints different types

### Versions

pytorch 1.6 gpu
onnx 1.8
onnxruntime 1.6 cpu
DISABLED test_extract_gradients_from_optimizer_set_to_none (__main__.TestIdentifyGradients)
Labels: module: flaky-tests, skipped, oncall: profiler

Platforms: mac, macos, win, windows

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_extract_gradients_from_optimizer_set_to_none&suite=TestIdentifyGradients) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/9376140274).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 2 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT BE ALARMED IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_extract_gradients_from_optimizer_set_to_none`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @robieta @chaekit @aaronenyeshi @ngimel @nbcsm @guotuofeng @guyang3532 @gaoteng-git @tiffzhaofb
forward AD for _euclidean_dist
Labels: module: autograd, triaged, actionable, module: forward ad, module: functorch

### 🚀 The feature, motivation and pitch

Submitting this feature request to get functorch.hessians downstream of torch.cdist, and the error issued by pytorch asked me to submit this to prioritize this. 

### Alternatives

I'll try autograd hessian. 

### Additional context

<img width="1035" alt="image" src="https://user-images.githubusercontent.com/4132346/200657073-54ef92cf-9c51-4f4b-9f57-ac47159c5d88.png">


cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @Chillee @samdow @soumith
API For Registering Stride Preferences For User Fallback Kernels
Labels: triaged, oncall: pt2

Calling `.contiguous()` or `.contiguous(memory_format=torch.channels_last)` within extern kernels instead of the inputs being passed in the right layout can lead to perf regression as seen by https://github.com/pytorch/torchdynamo/issues/1833. 

We should either have an API for registering stride preferences or default to contiguous.

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
nn.Linear allocate too many space which lead to CPUAllocator "allocate memory failure" if it's BF16. good for FP32.
Labels: module: cpu, triaged, intel

### 🐛 Describe the bug

Torch version: 1.13.0+cpu

BF16 code

```python
from torch import nn
import torch
lm_head = nn.Linear(1536, 250880, bias=False, dtype=torch.bfloat16)
input=torch.ones(size=(8,1024,1536), dtype=torch.bfloat16)
output=lm_head(input)
```

crash:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/skyrex05/wangyi/miniconda3/envs/compatibility_test/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/skyrex05/wangyi/miniconda3/envs/compatibility_test/lib/python3.9/site-packages/torch/nn/modules/linear.py", line 114, in forward
    return F.linear(input, self.weight, self.bias)
RuntimeError: [enforce fail at alloc_cpu.cpp:75] err == 0. DefaultCPUAllocator: can't allocate memory: you tried to allocate 189079224448 bytes. Error code 12 (Cannot allocate memory)


FP32 code

```python
from torch import nn
import torch
lm_head = nn.Linear(1536, 250880, bias=False)
input=torch.ones(size=(8,1024,1536))
output=lm_head(input)
```

no crash

### Versions

PyTorch version: 1.13.0+cpu
Is debug build: False
CUDA used to build PyTorch: Could not collect
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.5 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.9.13 (main, Oct 13 2022, 21:15:33)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-46-generic-x86_64-with-glibc2.31
Is CUDA available: False
CUDA runtime version: 10.1.243
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] intel-extension-for-pytorch==1.12.300
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.23.4
[pip3] torch==1.13.0+cpu
[pip3] torchaudio==0.13.0+cpu
[pip3] torchvision==0.14.0+cpu
[conda] intel-extension-for-pytorch 1.12.300                 pypi_0    pypi
[conda] numpy                     1.23.4                   pypi_0    pypi
[conda] torch                     1.13.0+cpu               pypi_0    pypi
[conda] torchaudio                0.13.0+cpu               pypi_0    pypi
[conda] torchvision               0.14.0+cpu               pypi_0    pypi


cc @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
Minifier crash
Labels: triaged, bug, oncall: pt2

### 🐛 Describe the bug

Minifier launcher: https://gist.github.com/5f8a42f8f0f72ab96e82a098fa147462

Run on a781b92acd8098018521addc4fbb184ded83e914 (latest symbolic-shapes branch at time of writing) with `TORCHDYNAMO_DYNAMIC_SHAPES=1 AOT_DYNAMIC_SHAPES=1`

Crashes with:

```
  File "/scratch/ezyang/work/pytorch/functorch/_src/fx_minifier.py", line 267, in try_granularity
    new_state = strategy(failing_state, granularity)
  File "/scratch/ezyang/work/pytorch/functorch/_src/fx_minifier.py", line 104, in new_func
    new_state = strategy(deepcopy_fx_graph(old_state.graph), list(old_state.inps), granularity)
  File "/scratch/ezyang/work/pytorch/functorch/_src/fx_minifier.py", line 245, in delta_debugging
    if graph_fails(new_state.graph, new_state.inps):
  File "/scratch/ezyang/work/pytorch/functorch/_src/fx_minifier.py", line 92, in graph_fails
    return module_fails(mod, inps)
  File "/scratch/ezyang/work/pytorch/torch/_dynamo/debug_utils.py", line 670, in backend_accuracy_fails
    compiled_gm = compiler_fn(copy.deepcopy(gm), clone_inputs(example_inputs))
  File "/scratch/ezyang/work/pytorch/torch/_dynamo/optimizations/training.py", line 94, in compile_fn
    return cls(gm, example_inputs).verified_candidate()
  File "/scratch/ezyang/work/pytorch/torch/_dynamo/optimizations/training.py", line 116, in __init__
    if not is_aot_autograd_safe_to_run(gm, example_inputs):
  File "/scratch/ezyang/work/pytorch/torch/_dynamo/optimizations/training.py", line 64, in is_aot_autograd_safe_to_run
    mutated = has_mutation(gm, example_inputs, inputs_only=True)
  File "/scratch/ezyang/work/pytorch/torch/_dynamo/optimizations/analysis.py", line 144, in has_mutation
    ShapeAliasingAndMutationProp(new_gm).run(*example_inputs)
  File "/scratch/ezyang/work/pytorch/torch/_dynamo/optimizations/analysis.py", line 113, in run
    super().run(*args)
  File "/scratch/ezyang/work/pytorch/torch/fx/interpreter.py", line 130, in run
    self.env[node] = self.run_node(node)
  File "/scratch/ezyang/work/pytorch/torch/_dynamo/optimizations/analysis.py", line 48, in run_node
    result = getattr(self, n.op)(n.target, args, kwargs)
  File "/scratch/ezyang/work/pytorch/torch/fx/interpreter.py", line 288, in call_module
    return submod(*args, **kwargs)
  File "/scratch/ezyang/work/pytorch/torch/nn/modules/module.py", line 1423, in _call_impl
    return forward_call(*input, **kwargs)  
  File "/scratch/ezyang/work/pytorch/torch/nn/modules/conv.py", line 463, in forward
    return self._conv_forward(input, self.weight, self.bias)
  File "/scratch/ezyang/work/pytorch/torch/nn/modules/conv.py", line 459, in _conv_forward
    return F.conv2d(input, weight, bias, self.stride,
RuntimeError: Expected 3D (unbatched) or 4D (batched) input to conv2d, but got input of size: [768]

While executing %self_self_blocks_0_local_mp_conv1 : [#users=1] = call_module[target=self_self_blocks_0_local_mp_conv1](args = (%reshape_3,), kwargs = {})
```

### Error logs

_No response_

### Minified repro

_No response_

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh
`MultiMarginLoss` doesn't check the value of `target` on CUDA
Labels: module: cuda, module: error checking, triaged

### 🐛 Describe the bug

`MultiMarginLoss` doesn't check the value of `target` on CUDA.

By the [doc](https://pytorch.org/docs/stable/generated/torch.nn.MultiMarginLoss.html) of `MultiMarginLoss`, the value of target should be `0<=v<=C−1`, where the shape of input is `C` or `N,C`. The CPU does check the validity of the value of `target` but CUDA will not and may return a value for some invalid `target`

```py
import torch

torch.manual_seed(420)
input = torch.randn(3, 5, requires_grad=True).cuda()
target = torch.tensor([1, 0, 5]).cuda()

loss = torch.nn.MultiMarginLoss()
output = loss(input, target)

print(output)
# CUDA
# tensor(0.7524, device='cuda:0', grad_fn=<MultiMarginLossBackward0>)
```

By contrast,

```py
import torch

torch.manual_seed(420)
input = torch.randn(3, 5, requires_grad=True)
target = torch.tensor([1, 0, 5])

loss = torch.nn.MultiMarginLoss()
output = loss(input, target)
# CPU
# RuntimeError: target out of range
```

### Versions

Collecting environment information...
PyTorch version: 1.12.1+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.6
Libc version: glibc-2.26

Python version: 3.7.15 (default, Oct 12 2022, 19:14:55) [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.133+-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: True
CUDA runtime version: 11.2.152
CUDA_MODULE_LOADING set to:
GPU models and configuration: GPU 0: Tesla T4
Nvidia driver version: 460.32.03
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.12.1+cu113
[pip3] torchaudio==0.12.1+cu113
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.13.1
[pip3] torchvision==0.13.1+cu113
[conda] Could not collect

cc @ngimel
`ConvTranspose` fails on CPU but returns an empty tensor on CUDA
Labels: module: cuda, module: error checking, triaged

### 🐛 Describe the bug

`ConvTranspose` fails on CPU but returns an empty tensor on CUDA

```py
import torch

input = torch.randn(1, 1, 2, 2, requires_grad=True)
weight = torch.randn(1, 1, 2, 2, requires_grad=True)
output = torch.nn.functional.conv_transpose2d(input, weight, stride=2, padding=2)
# CPU
# RuntimeError: Given input size per channel: (2 x 2). Calculated output size per channel: (0 x 0). Output size is too small
```

```py
import torch

input = torch.randn(1, 1, 2, 2, requires_grad=True).cuda()
weight = torch.randn(1, 1, 2, 2, requires_grad=True).cuda()
output = torch.nn.functional.conv_transpose2d(input, weight, stride=2, padding=2)
print(output)
# CUDA
# tensor([], device='cuda:0', size=(1, 1, 0, 0), grad_fn=<ConvolutionBackward0>)
```

I think they should both raise an error or succeed in this case

### Versions

Collecting environment information...
PyTorch version: 1.12.1+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.6
Libc version: glibc-2.26

Python version: 3.7.15 (default, Oct 12 2022, 19:14:55) [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.133+-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: True
CUDA runtime version: 11.2.152
CUDA_MODULE_LOADING set to:
GPU models and configuration: GPU 0: Tesla T4
Nvidia driver version: 460.32.03
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.1.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.12.1+cu113
[pip3] torchaudio==0.12.1+cu113
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.13.1
[pip3] torchvision==0.13.1+cu113
[conda] Could not collect

cc @ngimel @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
GitHub first-time contributors box pops up unexpectedly
Labels: module: ci, triaged

### 🐛 Describe the bug

For example, https://github.com/pytorch/pytorch/pull/88504

![Screen Shot 2022-11-07 at 16 46 37](https://user-images.githubusercontent.com/475357/200446531-be43c56d-22c7-488b-bdcd-bcbd075a2f8e.png)

After a quick check, it seems that the issue comes from the new [check-labels](https://github.com/pytorch/pytorch/blob/master/.github/workflows/check-labels.yml) workflow.  There are multiple instances of it shows up on the example PR https://github.com/pytorch/pytorch/pull/88504/checks and one of them requires approval from maintainer https://github.com/pytorch/pytorch/actions/runs/3395637495

![Screen Shot 2022-11-07 at 16 51 09](https://user-images.githubusercontent.com/475357/200447028-0d2c02e3-6262-427e-8e8f-e05c1894db01.png)



### Versions

CI workflow

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Cloud-based rendezvous backend / distributed store?
Labels: oncall: distributed

We're submitting elastic PyTorch runs on top of Azure Machine Learning

The two in-built rendezvous backends are c10d and etcd. We were wondering if you considered a rendezvous backend based on a cloud storage provider?

Both c10d and etcd require a stable endpoint / dedicated compute. (c10d requires a stable master node in the training cluster, and etcd requires a stable etcd server running on dedicated compute.) We're trying to train only on top of low-priority Spot VMs, which can enter / leave the training at any time.

To unblock ourselves, we implemented `AzureBlobRendezvousBackend` on top of `torch.distributed.elastic.rendezvous.dynamic_rendezvous.RendezvousBackend` and `AzureBlobStore` on top of `torch.distributed.Store`. Using Azure Blob as the key-value store, we didn't need an endpoint hosted by separate dedicated compute.

We were wondering if you've considered this approach before?

(Also, in the same spirit, in addition to `torch.distributed.FileStore`, have you considered something like `FolderStore`, which would be like `FileStore`, but where each key-value pair is stored in a separate file? If this had been present, we could have avoided implementing `AzureBlobStore`. Instead, we could have configured the nodes to use a common file system and then used `FolderStore`. (The common file system could have been a mounted Blob store, a shared NFS, etc.))


cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
[FSDP] FSDP produces different gradient norms vs DDP, and w/ grad norm clipping creates different training results
Labels: oncall: distributed, triaged, release notes: distributed (fsdp)

### 🐛 Describe the bug

Running a T5 large on C4 dataset, and using same random seeding, optimizer, lr scheduler, etc, training with DDP vs FSDP NO_SHARD and FULL_SHARD produce different gradient norms and with norm clipping different training outcomes:

![comparison](https://user-images.githubusercontent.com/46302957/200437760-cb9df95e-0aa3-435a-a574-bed5bd4ff14e.png)

The core issue is shown in this logging of the gradient norms:
![comparison_norm](https://user-images.githubusercontent.com/46302957/200437875-f282d44f-b62b-4a25-baf3-a06b2b2ce236.png)


Details on grad norm calculations:
Training was run with l2 norm. 
FSDP uses FSDP clip_grad_norm_()
DDP uses nn.utils.clip_grad_norm_()

code:
~~~
if isinstance(model, FSDP):
                    # grad_norm_before_clip = get_grad_norm_fsdp(model, local_rank)
                    model.clip_grad_norm_(clip_th)
                    grad_norm_after_clip = get_grad_norm_fsdp(model, local_rank, model_sharding_strategy)
                else:
                    # grad_norm_before_clip = get_grad_norm_local(model)
                    nn.utils.clip_grad_norm_(model.parameters(), clip_th)
                    grad_norm_after_clip = get_grad_norm_local(model) 
 ~~~

For logging, this is the code used:
~~~
def get_grad_norm_local(model):
    total_norm = 0.0
    for p in model.parameters():
        local_norm = torch.linalg.vector_norm(p.grad, dtype=p.dtype)
        total_norm += local_norm ** 2
    return total_norm ** 0.5
    
def get_grad_norm_fsdp(model, rank, sharding_strategy=ShardingStrategy.FULL_SHARD):
    local_norm = get_grad_norm_local(model)
    op = torch.distributed.ReduceOp.SUM
    return_norm = local_norm.clone().detach().requires_grad_(False).to(rank)**2
    dist.all_reduce(return_norm, op=op)
    if sharding_strategy == ShardingStrategy.NO_SHARD:
        return_norm = return_norm / world_size
    return return_norm ** 0.5
~~~
 


### Versions

pending...opening issue from partner. 

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
[inductor] Accuracy failure in torchbench hf_T5
Labels: triaged, oncall: pt2

initially thought this was a DDP-Dynamo issue.  Turns out to be an inductor issue, with or without DDP.

Log: https://gist.github.com/wconstab/1dfd032ed5cf4ff86b105aa4da6fa32c#file-torchbench_hf_t5_inductor_ddp_no_optimimze-log

@anijain2305 could you triage this?  Insofar as, just close the issue if you are already aware/tracking this accuracy failure, or put it in a backlog otherwise?

cc @ezyang @soumith @msaroufim @ngimel @bdhirsh
The libtorch tests Simplify.{SimplifySymbolicMinMax,SimplifyNestedMax,SimplifyNestedMin} fail on Apple Silicon
Labels: oncall: jit, module: m1

### 🐛 Describe the bug

Following [these docs](https://github.com/pytorch/pytorch/blob/v1.13.0/docs/libtorch.rst#building-libtorch-using-python) to build libtorch v1.13.0, then running one of the test binaries:

```sh
gh repo clone pytorch/pytorch && cd pytorch
git checkout v1.13.0
git submodule update --init --recursive
mkdir build_libtorch && cd build_libtorch
python ../tools/build_libtorch.py
build/bin/test_tensorexpr
```

I get these errors:

```
[ RUN      ] Simplify.SimplifySymbolicMinMax
/Users/samueles/github/pytorch/pytorch/test/cpp/tensorexpr/test_simplify.cpp:1997: Failure
Expected: (nullptr) != (node_), actual: (nullptr) vs (nullptr)
[  FAILED  ] Simplify.SimplifySymbolicMinMax (0 ms)
[ RUN      ] Simplify.SimplifyNestedMax
/Users/samueles/github/pytorch/pytorch/test/cpp/tensorexpr/test_simplify.cpp:2020: Failure
Expected: (nullptr) != (max), actual: (nullptr) vs (nullptr)
[  FAILED  ] Simplify.SimplifyNestedMax (0 ms)
[ RUN      ] Simplify.SimplifyNestedMin
/Users/samueles/github/pytorch/pytorch/test/cpp/tensorexpr/test_simplify.cpp:2296: Failure
Expected: (nullptr) != (min), actual: (nullptr) vs (nullptr)
[  FAILED  ] Simplify.SimplifyNestedMin (0 ms)
```

### Versions

PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: macOS 12.6.1 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.202)
CMake version: version 3.24.2
Libc version: N/A

Python version: 3.9.7 (default, Sep 8 2021, 10:47:21) [Clang 12.0.5 (clang-1205.0.22.11)] (64-bit runtime)
Python platform: macOS-12.6.1-arm64-arm-64bit
Is CUDA available: N/A
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.23.2
[pip3] torch==1.12.1
[pip3] torchvision==0.13.1
[conda] Could not collect

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
The libtorch test ConstantPropagation.CustomClassesCanBePropagated fails on Apple Silicon
Labels: oncall: quantization, triaged, module: m1

### 🐛 Describe the bug

I have tried this both on v1.13.0 and on `master` (currently commit 23a3eb37cfa52fcbfb766bd733cfa60b28b83f42) and get the same error. Specifically (following [these docs](https://github.com/pytorch/pytorch/blob/v1.13.0/docs/libtorch.rst#building-libtorch-using-python)):

```sh
gh repo clone pytorch/pytorch && cd pytorch
git checkout v1.13.0
git submodule update --init --recursive
mkdir build_libtorch && cd build_libtorch
python ../tools/build_libtorch.py
build/bin/test_jit
```

Failing output:

```
[----------] 1 test from ConstantPropagation
[ RUN      ] ConstantPropagation.CustomClassesCanBePropagated
unknown file: Failure
C++ exception with description "Expected to not find "quantized::linear_prepack" but found it
  %0 : NoneType = prim::Constant()
  %11 : QInt8(3, 3, strides=[3, 1], requires_grad=0, device=cpu) = prim::Constant[value= 1  1  1  1  1  1  1  1  1 [ QuantizedCPUQInt8Type{3,3}, qscheme: per_tensor_affine, scale: 1, zero_point: 0 ]]()
  %8 : __torch__.torch.classes.quantized.LinearPackedParamsBase = quantized::linear_prepack(%11, %0)
                                                                  ~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
  return (%8)
From CHECK-NOT: quantized::linear_prepack
" thrown in the test body.
[  FAILED  ] ConstantPropagation.CustomClassesCanBePropagated (2 ms)
[----------] 1 test from ConstantPropagation (2 ms total)
```

### Versions

Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: macOS 12.6.1 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.202)
CMake version: version 3.24.2
Libc version: N/A

Python version: 3.9.7 (default, Sep  8 2021, 10:47:21)  [Clang 12.0.5 (clang-1205.0.22.11)] (64-bit runtime)
Python platform: macOS-12.6.1-arm64-arm-64bit
Is CUDA available: N/A
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.23.2
[pip3] torch==1.12.1
[pip3] torchvision==0.13.1
[conda] Could not collect

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
Bernoulli uses legacy contiguous memory format
Labels: triaged, module: memory format

### 🐛 Describe the bug

```
RuntimeError: output 0: meta disagrees with real impl:
aten.bernoulli.default(
  tensor(..., device='meta', size=(2, 3, 4)) stride=(1, 2, 6),
  
) = (
  tensor(..., device='meta', size=(2, 3, 4)) stride=(1, 2, 6)
)
but real stride was (12, 4, 1)
```

after patching in bernoulli metas

```
+@register_meta([aten.bernoulli.default, aten.bernoulli.out])
+@out_wrapper()
+def meta_bernoulli(self, *, generator=None):
+    return torch.empty_like(self)
+
+
 @register_meta(aten.bernoulli_.float)
 def meta_bernoulli_(self, p=0.5, generator=None):
     return self
 
 
+@register_meta(aten.bernoulli.p)
+def meta_bernoulli_p(self, p=0.5, generator=None):
+    return torch.empty_like(self)
+
+
```

python test/test_meta.py -k test_dispatch_symbolic_meta_outplace_all_strides_bernoulli_cuda_float32

cpu passes with these metas

### Versions

master

cc @VitalyFedyunin @jamesr66a
quantization convert should warn the user if calibration has not happened
Labels: oncall: quantization, triaged

### 🐛 Describe the bug

It's an easy mistake to pass the wrong model into `prepare_fx`, such as

```
import copy
import torch
import torch.ao.quantize_fx as quantize_fx

m = M(...)
mp = prepare_fx(copy.deepcopy(m), ...)
# wrong model used for calibration
calibrate(m, data_loader)
mq = convert_fx(mp)
evaluate(mq, data_loader)
```

Currently there is no way for user to realize the mistake until after they evaluated the accuracy, which can take awhile depending on model/dataset.  If the user is doing static quantization, we should warn the user during convert if any activation observers have not seen any data.

### Versions

master

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @jgong5 @Xia-Weiwen @leslie-fang-intel
Despite having aten::diag_embed.out, torch.diag_embed doesn't support out= argument
Labels: triaged, module: codegen

### 🐛 Describe the bug

Discovered while working on https://github.com/pytorch/pytorch/pull/88584 You can test by trying to call diag_embed with an out= argument.

I think it has to do with the autogenerated schema machinery, as I don't see a denylist for diag_embed anywhere in codegen

cc @bhosmer @bdhirsh 

### Versions

master