Repository: pytorch
Issue: Build error on libstc++ header stl_alogbase.h on riscv
Labels: module: build,good first issue,triaged

### 🐛 Describe the bug

I am currently trying to build PyTorch using the latest master commit (fdbc8625a1a255cc7156cbbe54f681851de96c5f) on riscv. While so far I encountered another issue that was clearly caused by compiling for riscv, this error might be a general issue:

```c++
[ 78%] Building CXX object test_api/CMakeFiles/test_api.dir/init.cpp.o
In file included from /usr/include/c++/12/memory:63,
                 from /home/user/git/pytorch/third_party/googletest/googletest/include/gtest/gtest.h:57,                                                                                                           
                 from /home/user/git/pytorch/test/cpp/api/dataloader.cpp:1:
In static member function _static _Tp* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*) [with _Tp = long unsigned int; bool _IsMove = false]_,
    inlined from __OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = const long unsigned int*; _OI = long unsigned int*]_ at /usr/include/c++/12/bits/stl_algobase.h:495:30,
    inlined from __OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = const long unsigned int*; _OI = long unsigned int*]_ at /usr/include/c++/12/bits/stl_algobase.h:522:42,
    inlined from __OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = __gnu_cxx::__normal_iterator<const long unsigned int*, vector<long unsigned int> >; _OI = __gnu_cxx::__normal_iterator<lo
ng unsigned int*, vector<long unsigned int> >]_ at /usr/include/c++/12/bits/stl_algobase.h:529:31,
    inlined from __OI std::copy(_II, _II, _OI) [with _II = __gnu_cxx::__normal_iterator<const long unsigned int*, vector<long unsigned int> >; _OI = __gnu_cxx::__normal_iterator<long unsigned int*, vector<long u
nsigned int> >]_ at /usr/include/c++/12/bits/stl_algobase.h:620:7,
    inlined from _std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = long unsigned int; _Alloc = std::allocator<long unsigned int>]_ at /usr/include/c++/12
/bits/vector.tcc:244:21:
/usr/include/c++/12/bits/stl_algobase.h:431:30: error: argument 1 null where non-null expected [-Werror=nonnull]
  431 |             __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
      |             ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/12/bits/stl_algobase.h:431:30: note: in a call to built-in function _void* __builtin_memmove(void*, const void*, long unsigned int)_
[ 78%] Building CXX object test_api/CMakeFiles/test_api.dir/jit.cpp.o
At global scope:
cc1plus: note: unrecognized command-line option _-Wno-aligned-allocation-unavailable_ may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option _-Wno-unused-private-field_ may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option _-Wno-invalid-partial-specialization_ may have been intended to silence earlier diagnostics
cc1plus: some warnings being treated as errors
gmake[2]: *** [test_api/CMakeFiles/test_api.dir/build.make:118: test_api/CMakeFiles/test_api.dir/dataloader.cpp.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
```

My first guess is that this is an unlucky combination of the libstc++ version, compiler version and the `-Werror=nonnull` flag. I will try to set up the same build on an x86 machine but this might take some time.  I will also try to compile using the tagged 2.0.0 version and report if this changes something.

Note for riscv compilation (In case someone wants to reproduce this exactly):
The third-party lib SLEEF (https://github.com/shibatch/sleef) will only compile with the small fix from https://github.com/shibatch/sleef/pull/448. It is e.g. possible to compile SLEEF separately with the fix included and use `USE_SYSTEM_SLEEF=ON` for compiling PyTorch.

Addition: Kineto also does not build for now, and can be disabled with `USE_KINETO=0`.


### 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: Debian GNU/Linux bookworm/sid (riscv64)
GCC version: (Debian 12.2.0-10) 12.2.0
Clang version: 14.0.6
CMake version: version 3.25.1
Libc version: glibc-2.36

Python version: 3.10.9 (main, Dec  7 2022, 13:47:07) [GCC 12.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-starfive-riscv64-with-glibc2.36
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

CPU:
Architecture:        riscv64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3

Versions of relevant libraries:
[pip3] numpy==1.24.2
[conda] Could not collect


cc @malfet @seemethere