Repository: pytorch
Issue: ppc64le: test cpp_extensions/rng_extension.cpp failure (without altivec override)
Labels: triaged,module: random,module: POWER

## 🐛 Bug

When building the cpp_extensions tests from the master branch, on ppc64le platform, the compilation fails on the (somewhat) recent addition of rng_extension.cpp.
Note that this is in the test subdirectory, `test/cpp_extensions/rng_extension.cpp`. The
build of pytorch itself has lately been completing fine.

This file itself seems to have been added in late March under PR #34774.

The error itself is hundreds of lines long so I won't post it here, but an example can be seen at
the end of the output of one of the recent nightly CI runs, such as:
https://powerci.osuosl.org/job/pytorch-master-nightly-py3-linux-ppc64le-gpu/838/console

However, to simplify with what I have found, I have isolated the failing underlying command to this: 
`gcc -pthread -B /home/jenkins/miniconda/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/jenkins/miniconda/lib/python3.7/site-packages/torch/include -I/home/jenkins/miniconda/lib/python3.7/site-packages/torch/include/torch/csrc/api/include -I/home/jenkins/miniconda/lib/python3.7/site-packages/torch/include/TH -I/home/jenkins/miniconda/lib/python3.7/site-packages/torch/include/THC -I/home/jenkins/miniconda/include/python3.7m -c rng_extension.cpp -o rng_extension.o -g -DTORCH_API_INCLUDE_EXTENSION_H -DTORCH_EXTENSION_NAME=rng -D_GLIBCXX_USE_CXX11_ABI=1  -std=c++14`

Now, to see the above compilation succeed, one can just add `-mno-altivec` to the command above.  (In my trial, I added it as arg1 immediately after gcc).  I believe this tracks to a lack of altivec support within pytorch for ppc64le, related to the Feature Request numbered 27678. So in a way this would be expected to fail -- except that if the support isn't there, this part of the testing shouldn't be run on the platform; since the function isn't universal, the test element should ideally have a guard check such that it be run contingent on whether it is applicable.  (e.g. "if platform is not ppc64le, then...").

I admit I don't personally understand the full implication of building this cpp_extension without altivec versus skipping the test altogether (if it is actually not applicable), but I welcome suggestions on what would be appropriate.

## To Reproduce

Described above: attempt compilation on the PPC64LE platform using the command above.

## Expected behavior
In this case, I'd expect the test to be conditionally excluded as inapplicable, where appropriate.  (ppc64le at least; I don't know if there are other scenarios).

## Environment

Key element here I think is only that the system be on ppc64le.  I'm running in a RHEL container
with cuda 10.2, python 3.7, building in a conda environment.  The ENTIRE build output can be seen in the nightly ppc64le CI runs, such as the one in the first link above.

NOTE: I would welcome any suggestions on build script updates to skip over this in the interim, while this issue exists, to allow the nightly pytorch CI to go through the rest of the pytorch tests. ( I can directly access and edit the build parameters for the ppc64le CI runs.)


cc @pbelevich