gopikrsmscs/torch-issues huggingface dataset:
[CI] Split up periodic.yml into forward-fixable.yml and periodic.yml
Labels: module: ci, triaged

We want to move toward a future where we do not revert people based on periodic failures (and instead opt for forward fixing). To get there, we should:

1. Split up periodic.yml into two parts. Both should be periodic, but we should start creating a distinction between forward-fixable periodic tests and ones that we will revert devs for. Eventually, we want to move the second portion of tests to trunk/land validation.
2. forward-fixable should thus neither be included in our reliability stats nor block viable/strict upgrades

cc @seemethere @malfet @pytorch/pytorch-dev-infra
DPP training incompatibility with checkpoint and detach
Labels: oncall: distributed, triaged, module: ddp

### 🐛 Describe the bug

I am using pytorch ddp to train my model. Turns out if I use ddp, then I can not use checkpoint or detach gradient. The incompatibility is a big problem, because these techniques are important for my use.

My model consists of two part roughly, a language model for generate representation,  where weights are detached, another part of the model is trained  with gradients. 

the code of the language model:
```python
if exists(config.msa_bert.msa_bert_config.model_weight) and not config.msa_bert.skip_load_msa_bert:
                self.bert_model = load_pretrain(self.bert_model, config.msa_bert.msa_bert_config.model_weight)

if config.msa_bert.msa_bert_config.freeze:
    print('    frezze pretrained msa transformer')
    for param in self.bert_model.parameters():
        param.detach_()
    self.bert_model.eval()

```
Note in the other part of my model, there are recycles with detach.
```python
for i in range(n_recycle):
            msa_fea, pair_fea = self.feat_extractor(msa_fea, pair_fea)
            msa_fea, pair_fea = msa_fea.detach_(), pair_fea.detach_()
```
When using ddp, I have to turn on the `find_unused_parameters=True `, otherwise a error would be raised: `RuntimeError: Expected to have finished reduction in the prior iteration before starting a new one. `
Seems like if you have a model with detached params, you have to turn on this.
Here comes the problem, if I keep `find_unused_parameters=True ` and enable checkpoint, an error would be raised because a variable is marked twice.
I conjecture that during forward, those detached parameters are marked as ready because of  `find_unused_parameters=True `, and somehow they are marked ready again and causes this error.

I am wondering in what cases  a param would be marked as ready again?
And, what does it means for a param to be marked as ready? I think it is something to do with the autograd and the gradient compute map.

I accidentally find a solution that turn off the recycle ( i.e.,  turn off detach) and checkpoint while keep  `find_unused_parameters=True `, the ddp training works.
However, the problem is I can not turn off them as they are important for the efficiency. Without checkpoint, the gpu memory would explode.




### Versions

python3.8

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501 @ezyang
make_fx + aot_autograd segfaults
Labels: module: crash, triaged, module: fx, fx, module: functorch

### 🐛 Describe the bug

An example is taken from the `aot_function` docstring and I tried using `make_fx` on the callable returned by `aot_function`:
```py
import torch
from functorch.compile import aot_function
from torch.fx.experimental.proxy_tensor import make_fx

def print_compile_fn(fx_module, args):
    return fx_module

fn = lambda x : x.sin().cos()
aot_fn = aot_function(fn, print_compile_fn)

x = torch.randn(4, 5, requires_grad=True)

print(aot_fn(x))

try:
    gm = make_fx(aot_fn)(x)
    gm.graph.print_tabular()
except Exception as e:
    print(e)
    raise e
```

### Versions

Latest master.

cc @ezyang @SherlockNoMad @zou3519 @Chillee @samdow
Updating the LTS version of the torch (1.8.2 -> 1.10.2\1.11.2?)
Labels: oncall: binaries, triaged

### 🚀 The feature, motivation and pitch

The current current version of LTS torch is already more than 4 versions behind the new one.

To maintain interprise projects, you want to update the version of the torus, or understand when it is planned to be done in order to plan your roadmaps.

### Alternatives

when is it planned to be done? to plan your roadmaps. 

https://discuss.pytorch.org/t/pytorch-lts-release-schedule/153282

### Additional context

recently released version of PL in which support for torch 1.8.2 has ceased


https://github.com/Lightning-AI/lightning/issues/14086

cc @ezyang @seemethere @malfet
torch.empty_strided argument 'size'and 'stride' documentation wrong
Labels: module: docs, triaged

### 📚 The doc issue

The argument ('size' and 'stride') written on the document is tuple. However, I found that when argument ('size' and 'stride') is list, this api also works.

```
import torch
results={}
arg_1 = [2,2]
arg_2 = [4,2]
arg_3 = "cpu"
results['res'] = torch.empty_strided(arg_1,arg_2,device=arg_3,)
```

### Suggest a potential alternative/fix

It would be better if the document could write as this: 
size (tuple/list of python:ints) – the shape of the output tensor
stride (tuple/list of python:ints) – the strides of the output tensor

cc @svekars @holly1238
FSDP init can crash with shared parameters
Labels: high priority, triage review, oncall: distributed, triaged, module: fsdp

### 🐛 Describe the bug

FSDP initialization can crash when modules with shared params are wrapped separately. For example, if wrap https://github.com/facebookresearch/multimodal/blob/679f3596e4c44b483c68d4023b24e3c7f77292b3/torchmultimodal/modules/losses/flava.py#L138 linear (decoder) separately from the main module and then wrap the main module with `device_id` argument, this will raise an error due to `bias` param being shared. The `bias` param would have already been moved to GPU by the linear wrapped FSDP unit, but then the higher-level wrapper would still expect it to be on CPU, resulting in this error: https://github.com/pytorch/pytorch/blob/9e65e93c39238ec05aa7913693d7c3e4523bf257/torch/distributed/fsdp/fully_sharded_data_parallel.py#L814

### Versions

main

cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
[JIT] Scripting modules fails for modules that contain nested NamedTuples
Labels: oncall: jit

### 🐛 Describe the bug

When scripting a module that contains a nested NamedTuple instance variable, scripting fails.

Repro:
```python
import torch

from typing import NamedTuple, List

class AA(NamedTuple):
    a: torch.Tensor

class BB(NamedTuple):
    a: AA

class MyModule(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.x = BB(AA(torch.rand(2, 2)))

    def forward(self, input: BB) -> torch.Tensor:
        return self.x.a.a

torch.jit.script(MyModule())

'''
Traceback (most recent call last):
  File "/data/users/dberard/scripts/oncall/jackie.py", line 19, in <module>
    torch.jit.script(MyModule())
  File "/data/users/dberard/pytorch/torch/jit/_script.py", line 1286, in script
    return torch.jit._recursive.create_script_module(
  File "/data/users/dberard/pytorch/torch/jit/_recursive.py", line 476, in create_script_module
    return create_script_module_impl(nn_module, concrete_type, stubs_fn)
  File "/data/users/dberard/pytorch/torch/jit/_recursive.py", line 542, in create_script_module_impl
    create_methods_and_properties_from_stubs(concrete_type, method_stubs, property_stubs)
  File "/data/users/dberard/pytorch/torch/jit/_recursive.py", line 393, in create_methods_and_properties_from_stubs
    concrete_type._create_methods_and_properties(property_defs, property_rcbs, method_defs, method_rcbs, method_defaults)
RuntimeError:
'Tuple[Tuple[Tensor]]' object has no attribute or method 'a'.:
  File "/path/to/repro.py", line 17
    def forward(self, input: BB) -> torch.Tensor:
        return self.x.a.a
               ~~~~~~~~ <--- HERE
'''
```

### Versions

master branch, `e3dd4242657232d4b404465f2df848050cd7f088`
Support for CSR Tensor with NN layers
Labels: module: sparse, module: nn, triaged

### 🐛 Describe the bug

When I try to pass a CSR tensor to a forward pass for a NN it outputs NaN.

Here is the NN:


```
class Net(torch.nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = GCNConv(292, 8)
        self.conv2 = GCNConv(8, 7)

    def forward(self, data):
         x, edge_index = data.x.to_dense(), data.edge_index
         x = self.conv1(x, edge_index)
         x = F.relu(x)
         x = F.dropout(x, training=self.training)
         x = self.conv2(x, edge_index)
         return F.log_softmax(x, dim=1)
```


Are there any specific reasons why CSR tensors are not supported yet?

### Versions

PyTorch 1.10

cc @nikitaved @pearu @cpuhrsch @amjames @bhosmer @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
New PR template suggests a pattern that does not close PR
Labels: triaged

### 🐛 Describe the bug

https://github.com/pytorch/pytorch/pull/81991 introduced new template, which makes it harder for new contributors to mark PRs as fixing particular issue

Also, it is more verbose when ignored, perhaps we should come up with strategy to skip it if not filled, otherwise committed PR descriptions looks as follows(from https://github.com/pytorch/pytorch/commit/8d1ff9fc5dc70bdc65a83748c01cddf187728452):
```
### Description
<!-- What did you change and why was it needed? -->

### Issue
<!-- Link to Issue ticket or RFP -->

### Testing
<!-- How did you test your change? -->

Pull Request resolved: https://github.com/pytorch/pytorch/pull/82505
Approved by: https://github.com/razarmehr, https://github.com/albanD
```

### Versions

CI
'Wav2Vec2ForCTC' object has no attribute 'conv'
Labels: oncall: quantization, triaged

### 🐛 Describe the bug

hi there.
i run my code on Colab.
i want to statically quantize my Wav2Vec model.
before that i try dynamic quantization but it was not useful because i didn't speed up inference time ,unfortunetly got slower than regular model.
but i got error:
`'Wav2Vec2ForCTC' object has no attribute 'conv'`
here is my code:

```
from transformers import Wav2Vec2ForCTC, Wav2Vec2Tokenizer
tokenizer = Wav2Vec2Tokenizer.from_pretrained("facebook/wav2vec2-base-960h")
model = Wav2Vec2ForCTC.from_pretrained("facebook/wav2vec2-base-960h")
input_values = tokenizer(audio, return_tensors = "pt").input_values
```
Quantize snippet:
```
model.eval()
model.qconfig = torch.quantization.get_default_qconfig('fbgemm')
model_fp32_fused = torch.quantization.fuse_modules(model, [['conv', 'relu']],inplace=True)
model_fp32_prepared = torch.quantization.prepare(model_fp32_fused)
model_fp32_prepared(input_values)
model_int8 = torch.quantization.convert(model_fp32_prepared)
res = model_int8(input_values)
```
and stacktrace:
   ```
     return modules[name]
   1207         raise AttributeError("'{}' object has no attribute '{}'".format(
-> 1208             type(self).__name__, name))
   1209 
   1210     def __setattr__(self, name: str, value: Union[Tensor, 'Module']) -> None:

AttributeError: 'Wav2Vec2ForCTC' object has no attribute 'conv'

```






### Versions

```
PyTorch version: 1.12.0+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.13 (default, Apr 24 2022, 01:04:09)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.4.188+-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: False
CUDA runtime version: 11.1.105
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.0.5
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.0+cu113
[pip3] torchaudio==0.12.0+cu113
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.13.0
[pip3] torchvision==0.13.0+cu113
[conda] Could not collect
```

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
TestCommon.test_dtypes error message is confusing
Labels: triaged, module: testing

### 🚀 The feature, motivation and pitch

Here's what I think test_dtypes is doing:
- for each dtype, check if `op(*args, **kwargs)` works
- if it works, then add the dtype to a list of "acceptable" dtypes
- if it fails, then don't add the dtype to a list of acceptable dtypes.

test_dtype suppresses the error messages of those failures. This is confusing, because the error message suggests that the supported dtypes are wrong, but something else (e.g. a change to torch.testing) could responsible:
"AssertionError: The supported dtypes for _refs.broadcast_shapes on device type cpu are incorrect!
The following dtypes did not work in forward but are listed by the OpInfo: {torch.float32}." Furthermore, it makes it more difficult to debug because there is no exception to do a backtrace from.

I don't know if it would make the UX worse, but could we include the error messages of failures in the error message?


### Alternatives

_No response_

### Additional context

_No response_
Implement refs.var as a real reference
Labels: triaged, open source, cla signed, module: primTorch, no-stale

### Description
This PR removes the use of `prims.var` in the implementation of the `var` reference because there's no need for `var` to be a primitive.

### Testing
No new tests are needed.


cc @ezyang @mruberry @ngimel @Lezcano @fdrocha @peterbell10
torch.bitwise_xor argument 'other' documentation wrong
Labels: module: docs, triaged

### 📚 The doc issue


The type of argument ('input' and 'other')  written on the document is the integral or boolean tensor. That is to say, parameters ('input' and 'other') must be a tensor. However, I found that when parameter 'other' is bool or number, this api also works.

```import torch
arg_1 = torch.randint(0,2,[3], dtype=torch.bool)
arg_2 = True
res = torch.bitwise_xor(arg_1,arg_2,)

import torch
arg_1 = torch.randint(-512,1024,[3], dtype=torch.int64)
arg_2 = 10
res = torch.bitwise_xor(arg_1,arg_2)
```

The parameter 'other' on above code works well on bool and int type data. 


### Suggest a potential alternative/fix

It would be better if the document could write as this: other(Tensor, bool, int) – the second input .

cc @svekars @holly1238
torchinductor fallback cannot deal op that returns tuple of list of tensors
Labels: triaged, oncall: pt2

```

Traceback (most recent call last):
  File "/data/sandcastle/boxes/fbsource/buck-out/v2/gen/fbcode/d5479947763d4841/hpc/torchrec/models/feed/benchmark/__vdd_benchmark__/vdd_benchmark#link-tree/torchinductor/graph.py", line 196, in call_function
    return lowerings[target](*args, **kwargs)
  File "/data/sandcastle/boxes/fbsource/buck-out/v2/gen/fbcode/d5479947763d4841/hpc/torchrec/models/feed/benchmark/__vdd_benchmark__/vdd_benchmark#link-tree/torchinductor/lowering.py", line 139, in wrapped
    return decomp_fn(*args, **kwargs)
  File "/data/sandcastle/boxes/fbsource/buck-out/v2/gen/fbcode/d5479947763d4841/hpc/torchrec/models/feed/benchmark/__vdd_benchmark__/vdd_benchmark#link-tree/torchinductor/lowering.py", line 583, in handler
    result = ir.FallbackKernel.create(kernel, *args)
  File "/data/sandcastle/boxes/fbsource/buck-out/v2/gen/fbcode/d5479947763d4841/hpc/torchrec/models/feed/benchmark/__vdd_benchmark__/vdd_benchmark#link-tree/torchinductor/ir.py", line 2264, in create
    return [
  File "/data/sandcastle/boxes/fbsource/buck-out/v2/gen/fbcode/d5479947763d4841/hpc/torchrec/models/feed/benchmark/__vdd_benchmark__/vdd_benchmark#link-tree/torchinductor/ir.py", line 2268, in <listcomp>
    example_output[i].device,
AttributeError: 'list' object has no attribute 'device'
```

Triggered by fbgemm.jagged_dense_dense_elementwise_add_jagged_output.default

to repro in fbcode, check out V2 of https://www.internalfb.com/diff/D38488051

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh
Adding a warning of non-compatibility with forward hooks for the fast path of TransformerEncoderLayer
Labels: triaged, oncall: transformer/mha

### 📚 The doc issue

In [TransformerEncoderLayer](https://pytorch.org/docs/stable/generated/torch.nn.TransformerEncoderLayer.html), it would be helpful if it explicitly points out that naive hooks tend not to work under `fast path`, see [this discussion](https://discuss.pytorch.org/t/register-forward-hook-doesnt-work-for-nestedtensor/158374/5).  The reason for such a notification is that **attention maps** are generally plotted when using Transformers, and hooking is debatably the most direct way to get attention weights.

### Suggest a potential alternative/fix

Add a warning notifying users that forward hooks might not be compatible with the fast path of `nn.TransformerEncoderLayer`.

cc @jbschlosser @bhosmer @cpuhrsch @erichan1
DISABLED test_tensorboard_trace_handler (__main__.TestProfiler)
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_tensorboard_trace_handler&suite=TestProfiler&file=test_profiler.py) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/7695478091).

Over the past 3 hours, it has been determined flaky in 1 workflow(s) with 1 red and 1 green.

cc @robieta @chaekit @aaronenyeshi @ngimel @nbcsm @guotuofeng @guyang3532 @gaoteng-git @tiffzhaofb
`torch.tensor` and `torch.as_tensor` keyword argument `device` documentation wrong
Labels: module: docs, triaged, module: tensor creation

### 📚 The doc issue

> device - the device of the constructed tensor. If None and data is a tensor then the device of data is used. If None and data is not a tensor then the result tensor is constructed on the CPU.

However, if None and data is not a tensor, then the result tensor actually is constructed on the current device for the default tensor type, like `torch.empty`, `torch.zeros` and `torch.ones`.

### Suggest a potential alternative/fix

the device of the constructed tensor. Default: If `None` and data is a tensor, uses the device of data. If `None` and data is not a tensor, uses the current device for the default tensor type (see [torch.set_default_tensor_type()](https://pytorch.org/docs/stable/generated/torch.set_default_tensor_type.html#torch.set_default_tensor_type)). [device](https://pytorch.org/docs/stable/tensor_attributes.html#torch.device) will be the CPU for CPU tensor types and the current CUDA device for CUDA tensor types.

cc @svekars @holly1238 @gchanan @mruberry
Unknown builtin op: torchvision::deform_conv2d
Labels: oncall: jit

### 🐛 Describe the bug

I have a model, in this model i have used torchvision.ops.DeformConv2D
then i traced this model with out any error.
but when i want to load this jit model in c++ liobtorch

"torch::jit::load();"

i got an error about Unknown builtin op: torchvision::deform_conv2d
my Version:
python3.8 :  torch 1.11.0-cpu
                   torchvision 0.12.0-cpu
c++ : libtorch 1.11.0-cpu


"
Unknown builtin op: torchvision::deform_conv2d.
Could not find any similar ops to torchvision::deform_conv2d. This op may not exist or may not be currently supported in TorchScript.
.......
Serialized   File "code/__torch__/torchvision/ops/deform_conv.py", line 14
    bias = self.bias
    weight = self.weight
    input = ops.torchvision.deform_conv2d(argument_1, weight, offset, mask, bias, 1, 1, 1, 1, 1, 1, 1, 1, True)
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
    return input
"

### Versions

my Version:
python3.8 :  torch 1.11.0-cpu
                   torchvision 0.12.0-cpu
c++ : libtorch 1.11.0-cpu
GPU arch 8.6 is not covered by the `TORCH_CUDA_ARCH_LIST = All` option 
Labels: module: build, module: cuda, triaged

### 🐛 Describe the bug

Since `TORCH_CUDA_ARCH_LIST = Common` covers 8.6, it's probably a bug that 8.6 is not included in `TORCH_CUDA_ARCH_LIST = All`.

`TORCH_CUDA_ARCH_LIST = All` will use  `CUDA_KNOWN_GPU_ARCHITECTURES`,
https://github.com/pytorch/pytorch/blob/bfebf254dd92f3ed35154597166e7e71fb04f31b/cmake/Modules_CUDA_fix/upstream/FindCUDA/select_compute_arch.cmake#L192-L193
whose latest arch is `"Ampere"`,
https://github.com/pytorch/pytorch/blob/bfebf254dd92f3ed35154597166e7e71fb04f31b/cmake/Modules_CUDA_fix/upstream/FindCUDA/select_compute_arch.cmake#L86
and `"Ampere"` adds 80 to bin/ptx only.
https://github.com/pytorch/pytorch/blob/bfebf254dd92f3ed35154597166e7e71fb04f31b/cmake/Modules_CUDA_fix/upstream/FindCUDA/select_compute_arch.cmake#L237-L239

### Versions

TOT

cc @malfet @seemethere @ngimel
getDLContext in DLConvertor.h cannot be found
Labels: triaged, module: dlpack

https://github.com/pytorch/pytorch/blob/67ece03c8cd632cce9523cd96efde6f2d1cc8121/aten/src/ATen/DLConvertor.h#L17
is not consistent with the definition in DLConvertor.cpp
https://github.com/pytorch/pytorch/blob/67ece03c8cd632cce9523cd96efde6f2d1cc8121/aten/src/ATen/DLConvertor.cpp#L71
functionalize and make_fx are not composable resulting in segfault and cuda error
Labels: module: crash, triaged, module: fx, fx, module: functorch

### 🐛 Describe the bug

This snippet segfaults with `device="cpu"` and gives a CUDA error with cuda device input.
```py
import torch
from functorch import make_fx
from functorch.experimental import functionalize

a = torch.randn(3, 3, device="cuda")

def fn(a):
    result = torch.empty_like(a)
    result.copy_(a)
    return result

try:
    functionalize(make_fx(fn))(a)
except Exception as e:
    print(e)
    print("functionalize failed")
```
```py
CUDA error: invalid argument
functionalize failed
```

### Versions

Latest master.

cc @ezyang @SherlockNoMad @zou3519 @Chillee @samdow @jjsjann123
[ROCm] build instruction is haphazard missing information unclear, build does not work
Labels: module: docs, module: rocm, triaged

### 🐛 Describe the bug

STARTED FROM https://pytorch.org/get-started/locally/ --> this has building from source link but ironically it link brings to "windows-from-source" i am not sure what it means, whoever has brought this URL must be some issue with English, nevertheless i decided to go there:
https://pytorch.org/get-started/locally/#windows-from-source
This page does not have a lot and then points to another one:
https://github.com/pytorch/pytorch#from-source

at this point, I am unclear why i have to go through 3 different pages to get the instruction for building:

This main page appears to be main instructions for building pytoch but RIDDLED with errors, haphazardly put information containing several different ways of building but ALL OF THEM DOES NOT work.

https://github.com/pytorch/pytorch#from-source

after satisfying all requirements including anaconda, upgraded python and bunch of libraries, some of them were specified in the page and some not (latter I had to find throuhg gruelling hours of struggle), build still fails

Anaconda3-2021.11-Linux-x86_64.sh  (installed this anaconda)
Python 3.9.10

Following steps ocurrs OK for radeon MI100:
git clone --recursive https://github.com/pytorch/pytorch
cd pytorch
# if you are updating an existing checkout
git submodule sync
git submodule update --init --recursive --jobs 0
python tools/amd_build/build_amd.py


but this following never works:

export CMAKE_PREFIX_PATH=${CONDA_PREFIX:-"$(dirname $(which conda))/../"}
python setup.py install

There is error about makefile missing.
POOR DOCUMENTATION!!

Decided to go manual by "cd pytorch ; mkdir build ; cd build ; cmake .. ; make -j16" it goes for about 88% and fails.

Try these steps on freshly installed Centos 8 Stream and i guaranteed you will never be able to build it with what is in there!

I just dont know how even basic build steps fail fail fail. 













### Versions

release/1.10

cc @svekars @holly1238 @jeffdaily @sunway513 @jithunnair-amd @ROCmSupport @KyleCZH
Profiling results on CPU is not reliable
Labels: module: performance, triaged

### 🐛 Describe the bug

Same as https://github.com/pytorch/kineto/issues/325, I used torch profiler to profile the inference of DL models, but the result of profiling is far from the measurement of directly running the model.
For example:
effiennet_b5 on A100:
Batch size: 1 (real time scenario), multi-instance (7 instances on 7 mig, each instance on one mig)
results of single instance:
```
benchmark time: 17.839 ms.
profiler time: Self CPU time total 30.498ms, Self CUDA time total: 17.447ms,  ProfilerStep* self cpu 6.493ms 
```
![Screenshot (346)](https://user-images.githubusercontent.com/23565213/182764329-abeec8eb-272b-487d-a04f-f3f701217c61.png)


self CPU time total 30.498ms - ProfilerStep* self cpu 6.493ms is still much larger than  benchmark time 17.839 ms. 
I found the exact overhead number before: 4 us per op on CUDA, and the profiler overhead on CPU seems to be very large.
This makes performance analysis difficult.

### Versions

pytorch 1.12
python 3.8.5

cc @VitalyFedyunin @ngimel
[LibTorch] the C++ api needs detailed error reports like pytorch 
Labels: module: logging, triaged, enhancement

### 🚀 The feature, motivation and pitch

 
Basically, I am currently working with Libtorch (the C++ version of pytorch), and encountered a problem.

When any operations fails within the libtorch engine, it will raise a debug error as intended. However, unlike pytorch which reports the error in details through log messages, the libtorch debug window leads up to the point of execution termination in the "disassembly version" of my application.

<img width="797" alt="15e9bafce8b1bd35a56abf36dd30dbd" src="https://user-images.githubusercontent.com/61119095/182743523-963e9486-3626-496f-8cd2-5389cec0ddb1.png">

Although the stack trace provides the function that causes the error in LLDB,  and the annotations within disassembled binaries indicates that libtorch went through an error checking and report stage, no reasonings or error messages are given before the application terminates its execution.

This is extremely troublesome while debugging an application, since many functions can fail in multiple ways and there will be no way to know the reasons of failure directly from libtorch. 

Therefore, I would like the error loggings like pytorch to be also possible within libtorch, which will be a great help for me and other C++ developers working on this engine.

### Alternatives

_No response_

### Additional context

_No response_
UnaryUfuncInfo Sample Generation Ignores sample_kwarg function
Labels: high priority, triaged, module: correctness (silent), module: testing

### 🐛 Describe the bug

`op.sample_inputs` as is the common pattern throughout [test_ops](https://github.com/pytorch/pytorch/blob/master/test/test_ops.py) etc ignores the `sample_kwarg` that is passed into the UnaryUFunc OpInfo. 

As a result, no kwargs are passed in / tested. 

repro run `python test/test_ops.py -k test_fake_nan_to_num_cpu_float32` and print kwargs.

### Versions

master

cc @ezyang @gchanan @zou3519
Subclass of Tensor doesn't support __format__
Labels: triaged, tensor subclass

### 🐛 Describe the bug

```__format__``` on a 0-dimension tensor works if the class is ```torch.Tensor```, but fails with a subclass. (Tripped over this when using fastai, which subclasses Tensor.)

```
from torch import Tensor, tensor

x = Tensor(tensor(4.8801))
print(x.__format__('.4f'))

class TensorSubclass(Tensor):
    pass

y = TensorSubclass(tensor(4.8801))
print(y.__format__('.4f'))
```
```
4.8801
Traceback (most recent call last):
  File "main.py", line 10, in <module>
    print(y.__format__('.4f'))
  File ".../pytorch/torch/_tensor.py", line 842, in __format__
    return handle_torch_function(Tensor.__format__, (self,), self, format_spec)
  File ".../pytorch/torch/overrides.py", line 1530, in handle_torch_function
    result = torch_func_method(public_api, types, args, kwargs)
  File ".../pytorch/torch/_tensor.py", line 1263, in __torch_function__
    ret = func(*args, **kwargs)
  File ".../pytorch/torch/_tensor.py", line 845, in __format__
    return object.__format__(self, format_spec)
TypeError: unsupported format string passed to TensorSubclass.__format__
```

### Versions

PyTorch version: 1.13.0a0+gitf4ee374
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.5 (x86_64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.5)
CMake version: version 3.23.3
Libc version: N/A

Python version: 3.9.12 (main, Jul 29 2022, 10:53:31)  [Clang 13.1.6 (clang-1316.0.21.2.5)] (64-bit runtime)
Python platform: macOS-12.5-x86_64-i386-64bit
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.22.4
[pip3] torch==1.13.0a0+gitf4ee374
[pip3] torchaudio==0.13.0.dev20220801
[pip3] torchvision==0.14.0.dev20220801
[conda] Could not collect

cc @ezyang
Fill in a bool Tensor not supported in jit
Labels: oncall: jit

### 🐛 Describe the bug

Fill in a bool Tensor not supported in jit 

```python
import torch

class Dumbo(torch.nn.Module):
    def forward(self, x):
        x_mask = torch.zeros(x.shape, dtype=torch.bool)
        x_mask[:,:] = True
        return x_mask + x


x = torch.rand(2, 3)
import io
torch.onnx.export(Dumbo(), (x, ), io.BytesIO())
```

Error message is as follows

```
RuntimeError: 0INTERNAL ASSERT FAILED at "/opt/conda/conda-bld/pytorch_1646755903507/work/torch/csrc/jit/ir/alias_analysis.cpp":607, please report a bug to PyTorch. We don't have an op for aten::fill_ but it isn't a special case.  Argument types: Tensor, bool, 

Candidates:
        aten::fill_.Scalar(Tensor(a!) self, Scalar value) -> (Tensor(a!))
        aten::fill_.Tensor(Tensor(a!) self, Tensor value) -> (Tensor(a!))
```

Current workaround, replace

```
x_mask = torch.zeros(x.shape, dtype=torch.bool)
x_mask[:,:] = True
```

with

```
x_mask = torch.zeros(x.shape)
x_mask[:,:] = 1
```



### Versions

Python version: 3.8.12 (default, Oct 12 2021, 13:49:34) [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.15.0-1014-azure-x86_64-with-glibc2.17
Is CUDA available: N/A
CUDA runtime version: Could not collect
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==0.950
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.6
[pip3] torch==1.13.0a0+gitf1aeea2
[pip3] torchvision==0.13.0a0+8e5844f
[conda] mkl 2022.0.1 h06a4308_117
[conda] mkl-include 2022.0.1 h06a4308_117
[conda] numpy 1.21.6 pypi_0 pypi
[conda] torch 1.13.0a0+git6997ac7 pypi_0 pypi
[conda] torchvision 0.13.0a0+8e5844f dev_0
torch.Tensor.bag() should automatically implement bagging
Labels: triaged, enhancement

### 🚀 The feature, motivation and pitch

Bootstrap aggregation, or bagging, is a common sampling technique in training ML models. For a dataset D of size N, bagging will randomly sample with replacement N data points from D. These bagged datasets can then be used to train an ensemble of models which will often outperform a single model trained on unbagged data (see Breiman, 1996). 

### Documentation

Tensor.bag(dim=0, n=1) should return a tensor of data points sampled randomly with replacement from the original tensor, and of the same size as that tensor. 

Dim refers the the dimension along which to randomly sample. 

N refers to the number of bagged datasets to return; if n>1, the tensor returned should include n independent bagged datasets of the same size as the original tensor. 

Out refers to what should be returned. The default is to return the bagged values. 'idx' should return the indices that would have been bagged, and 'both' should return a named tuple of both values and indices. 

### Questions
* Should the returned Tensor be a deep copy or simply a view of the original data? Views are sufficient if the data will not be transformed in the training process. But processing after bagging (e.g. normalizing the bagged dataset) would require a deep copy. Perhaps this should be an option, or two separate methods. 
* Is 'out' the correct way to handle this? What should be the default behavior, and what should the options be named?

### Alternatives

PyTorch could also implement the equivalent of numpy's np.random.choice(), which has an outstanding pull request as described in this issue: https://github.com/pytorch/pytorch/issues/16897

### Additional context

_No response_
Met bugs ERROR:torch.distributed.elastic.multiprocessing.api:failed (exitcode: -9) local_rank: 0
Labels: oncall: distributed, oncall: r2p

### 🐛 Describe the bug

I met bugs when I run distribute train. 
![image](https://user-images.githubusercontent.com/42291628/182712008-0389906c-84be-470d-9f49-bfa86d861cd0.png)

Package            Version
------------------ ----------------
certifi            2022.6.15
charset-normalizer 2.1.0
idna               3.3
numpy              1.23.1
Pillow             9.2.0
pip                22.1.2
PyYAML             6.0
requests           2.28.1
scipy              1.9.0
setuptools         61.2.0
timm               0.4.5
tlt                0.1.0
torch              1.12.0+rocm5.1.1
torchaudio         0.12.0+rocm5.1.1
torchvision        0.13.0+rocm5.1.1
typing_extensions  4.3.0
urllib3            1.26.11
wheel              0.37.1

### Versions

Collecting environment information...
PyTorch version: 1.12.0+rocm5.1.1
Is debug build: False
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: 5.1.20531-cacfa990

OS: Red Hat Enterprise Linux release 8.4 (Ootpa) (x86_64)
GCC version: (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1)
Clang version: Could not collect
CMake version: version 3.18.2
Libc version: glibc-2.28

Python version: 3.9.12 (main, Jun  1 2022, 11:38:51)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-4.18.0-305.28.1.el8_4.x86_64-x86_64-with-glibc2.28
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: 5.1.20531
MIOpen runtime version: 2.16.0
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.1
[pip3] torch==1.12.0+rocm5.1.1
[pip3] torchaudio==0.12.0+rocm5.1.1
[pip3] torchvision==0.13.0+rocm5.1.1
[conda] numpy                     1.23.1                   pypi_0    pypi
[conda] torch                     1.12.0+rocm5.1.1          pypi_0    pypi
[conda] torchaudio                0.12.0+rocm5.1.1          pypi_0    pypi
[conda] torchvision               0.13.0+rocm5.1.1          pypi_0    pypi

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
Refactor how errors decide whether to append C++ stacktrace
Labels: triaged, better-engineering

### 🚀 The feature, motivation and pitch

Per @zdevito's comment in https://github.com/pytorch/pytorch/pull/82665/files#r936022305, we should refactor the way C++ stacktrace is appended to errors.

Currently, in https://github.com/pytorch/pytorch/blob/752579a3735ce711ccaddd8d9acff8bd6260efe0/torch/csrc/Exceptions.h, each error goes through a try/catch and the C++ stacktrace is conditioned on whether cpp stacktraces are enabled or not.

Instead, specific exceptions can have a flag that determines whether cpp stacktrace is added or not. Most errors would set this in their constructor based on the env variable, but for certain types of errors which always report cpp stacktrace, this can just be set to true and this field can be checked when reporting errors.

### Alternatives

_No response_

### Additional context

_No response_
DecompositionInterpreter creates invalid graphs for FX graph modules created with torch.fx.symbolic_trace
Labels: triaged, module: fx, fx

### 🐛 Describe the bug

```py
import torch
from torch.fx.experimental.proxy_tensor import DecompositionInterpreter

class Model(torch.nn.Module):

    def __init__(self):
        super(Model, self).__init__()
        self.bn = torch.nn.BatchNorm2d(3)
        self.relu = torch.nn.ReLU()

    def forward(self, inp):
        o = self.bn(inp)
        o = self.relu(o)
        return o

input = torch.randn(2, 3, 4, 5)
m = Model()
gm = torch.fx.symbolic_trace(m)

graph = torch.fx.Graph()
DecompositionInterpreter(gm, graph).run(input)
print(graph)
```
```py
graph():
    %inp : [#users=1] = placeholder[target=inp]
    %native_batch_norm_default : [#users=3] = call_function[target=torch.ops.aten.native_batch_norm.default](args = (%inp, Parameter containing:
tensor([1., 1., 1.], requires_grad=True), Parameter containing:
tensor([0., 0., 0.], requires_grad=True), tensor([0.0085, 0.0026, 0.0262]), tensor([1.0102, 1.0085, 0.9952]), True, 0.1, 1e-05), kwargs = {})
    %getitem : [#users=1] = call_function[target=operator.getitem](args = (%native_batch_norm_default, 0), kwargs = {})
    %getitem_1 : [#users=0] = call_function[target=operator.getitem](args = (%native_batch_norm_default, 1), kwargs = {})
    %getitem_2 : [#users=0] = call_function[target=operator.getitem](args = (%native_batch_norm_default, 2), kwargs = {})
    %relu_default : [#users=2] = call_function[target=torch.ops.aten.relu.default](args = (%getitem,), kwargs = {})
    %detach_default : [#users=1] = call_function[target=torch.ops.aten.detach.default](args = (%relu_default,), kwargs = {})
    %detach_default_1 : [#users=0] = call_function[target=torch.ops.aten.detach.default](args = (%detach_default,), kwargs = {})
    return relu_default
```
Arguments to the `native_batch_norm_default` call contain repr of parameters instead of being referenced as constants.

The source of this problem is that `DecompositionInterpreter` uses `torch.fx.proxy.GraphAppendingTracer` instead of `torch.fx.experimental.proxy_tensor.PythonKeyTracer`.

### Versions

Latest master

cc @ezyang @SherlockNoMad @davidberard98
torchdynamo backend failure suppression is insufficient when backend fails at runtime
Labels: triaged, oncall: pt2

see https://github.com/pytorch/torchdynamo/pull/703 specifically https://app.circleci.com/pipelines/github/pytorch/torchdynamo/623/workflows/f8662ac5-4b8f-4a18-bd44-bd3b4808e581/jobs/635

it's possible that torchbenchmark.py is toggling some other config that is prevent the failures from being suppressed, but I removed the obvious command line flags that were unsuppressing failures.

cc @soumith @msaroufim @wconstab @ngimel @bdhirsh
Automating release process - Binary validation, Automatically generating get started page
Labels: module: ci, triaged

### Problems details
Validation Takes to much time and not automated
Binary builds presence and installation instructions are not tested against release 
Get Started page generation is not automated


Lack of validation for artifacts based on the release matrix. We publish the following [release matrix] (TO DO  MOVE MATRIX TO OSS), and we build, test and publish the binaries to multiple repositories, such as Conda, Wheels, pypi, Iphone cocoapods, Android Maven. We publish for multiple OS versions (Linux, Windows, MacOs) and multiple package versions (CUDA, Python). However we have following gaps, for pytorch core and each of the domain libraries:
Smoke tests on clean environments are not implemented for all the binaries we produce (including Domain Libraries). To make sure binary can be loaded properly we should validate these binaries on the environment that does not have any dependencies preinstalled. 
Existing smoke tests run in the environment that has all dependencies preinstalled and hence we may miss an issue when the dependencies are missing
Binary presence and installation instructions validation for each binary. We already have a subset of the implemented when validating the get[ started page](https://pytorch.org/get-started/locally/). We also implemented a script to validate conda binaries presence. However we don’t validate all the binaries this way.

This situation leads to the following issues: 
Not releasing some binaries that are targeted for release
Releasing the binaries that could not be installed
Binaries fails to install due to regression of repository
Issues: [82428](https://github.com/pytorch/pytorch/issues/82428)
Releasing the binaries that could be installed but fails loading
Issues: [74087](https://github.com/pytorch/pytorch/issues/74087) [78490](https://github.com/pytorch/pytorch/issues/78490)

### Proposal

1. Ensure each release binary can be properly installed, and executed on target environment. 
Linux:

- [x] #83519
- [x] #84421
- [x] #82969
- [x] #82971
- [x] #82973

Windows:
- [x] #82977
- [x] #82978
- [x] #82980

Mac:
- [x] #83013
- [x] #83021

1.5 CUDA Older driver compatibility test:
- [x] #82913


2. Ensure we produce binary for every configuration declared in release matrix:
- [x] #82991

3. Generate a get started page automatically based on the release matrix.
- [x] #82996

4. Surface results on HUD and alerts for release failures
- [ ] #84422

5. Extend the validation tests to cover more use cases:
- [x] #85085

6. Automate release only changes that needs to happen in order to build the release
- [x] #86491

7. Fix Official Docker build for release
- [x] #87489

8. Synchronize domain builds to be executed after core build have completed
- [ ] #87501

9. Consolidate Pytorch core and  Validation system framework matrixes and smoke tests
- [ ] #88686

cc @seemethere @malfet
cur_dim == dimINTERNAL ASSERT FAILED at
Labels: module: onnx, triaged, onnx-triaged

https://github.com/pytorch/pytorch/blob/8da2b204e111ad0ea42d0b029eb6851f5fd2a95f/torch/csrc/jit/passes/onnx/pattern_conversion/pattern_conversion.cpp#L133
When there are some repeated aten::slices in the subblock, the dim_offset won't plus-plus leading to asserting error.

the sub block's torch script IR is as follows.
```torch script
%3865 : Float(450, 450, strides=[450, 1], requires_grad=0, device=cuda:0) = aten::select(%attention_mask, %4175, %4176) 
%3866 : Float(61, 450, strides=[450, 1], requires_grad=0, device=cuda:0) = aten::slice(%3865, %4179, %4180, %1741, %4181)
%3867 : Float(61, 450, strides=[450, 1], requires_grad=0, device=cuda:0) = aten::slice(%3866, %4184, %4185, %1749, %4186)
```
tensor.unfold don't check the parameter size value, that maybe less than 0. 
Labels: module: error checking, triaged, module: edge cases

### 🐛 Describe the bug

https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/TensorShape.cpp#L3144
Unfold op may create a tensor with negative value and cause failed. So maybe add a check of parameter size in this op.

>>> a = torch.randn((3,4,5,4))
>>> b = a.unfold(3,-1,1)
>>> b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/projs/framework/shangang/venv/pytorch_19/lib/python3.6/site-packages/torch/_tensor.py", line 212, in __repr__
    return torch._tensor_str._str(self)
  File "/projs/framework/shangang/venv/pytorch_19/lib/python3.6/site-packages/torch/_tensor_str.py", line 407, in _str
    return _str_intern(self)
  File "/projs/framework/shangang/venv/pytorch_19/lib/python3.6/site-packages/torch/_tensor_str.py", line 382, in _str_intern
    tensor_str = _tensor_str(self, indent)
  File "/projs/framework/shangang/venv/pytorch_19/lib/python3.6/site-packages/torch/_tensor_str.py", line 242, in _tensor_str
    formatter = _Formatter(get_summarized_data(self) if summarize else self)
  File "/projs/framework/shangang/venv/pytorch_19/lib/python3.6/site-packages/torch/_tensor_str.py", line 82, in __init__
    tensor_view = tensor.reshape(-1)
RuntimeError: Trying to create tensor with negative dimension -1: [3, 4, 5, 6, -1]

### Versions


master
Tensorboard py-profiler shows no device info in Operator view
Labels: oncall: profiler

### 🐛 Describe the bug

Following the official tutorial, i use the following code to profile my model. However, there is no device info collected/showed in Operator view.
```python
         with profile(
            activities=[ProfilerActivity.CUDA, ProfilerActivity.CPU],
            schedule=torch.profiler.schedule(
                skip_first=8,
                warmup=0,
                wait=0,
                active=2,
            ),
            on_trace_ready=torch.profiler.tensorboard_trace_handler('./pyprofile/tf_event/'),
            with_flops=True,
            with_modules=True,
            with_stack=True,
            record_shapes=True,
        ) as p:
            for i in range(self.config['max_iter']):
```

Here are my tensorboard snapshot where device duration and tensor core usage are all zeros, and no device bar chart is showed. 
<img width="1068" alt="截屏2022-08-03 下午7 14 24" src="https://user-images.githubusercontent.com/53320182/182594867-31e5baf4-89c4-4d4c-a6bd-d738ecf1ef31.png">





### Versions

PyTorch version: 1.12.0+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: CentOS Linux 7 (Core) (x86_64)
GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Clang version: Could not collect
CMake version: version 3.22.4
Libc version: glibc-2.28

Python version: 3.8.0 (default, Nov  6 2019, 21:49:08)  [GCC 7.3.0] (64-bit runtime)
Python platform: Linux-3.10.0-957.el7.x86_64-x86_64-with-glibc2.10
Is CUDA available: False
CUDA runtime version: 9.0.176
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/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.22.1
[pip3] spring==0.7.2+cu112.torch1120.mvapich2.pmi2.nartgpu.develop.b35cd03e
[pip3] torch==1.12.0+cu113
[pip3] torch-tb-profiler==0.4.0
[pip3] torchvision==0.11.3+cu113
[conda] Could not collect

cc @robieta @chaekit @aaronenyeshi @ngimel @nbcsm @guotuofeng @guyang3532 @gaoteng-git @tiffzhaofb