valgrind chokes on rdrand from gcc libstdc++

[ezyang]

I've attempted to use valgrind on PyTorch in the past and ran into https://bugs.kde.org/show_bug.cgi?id=387940

Apparently, the culprit was -march=native. If you're going to valgrind your PyTorch, you shouldn't build with this flag.

This issue is to track:

1. Testing that this indeed resolves the issue
2. Making it easy to turn of -march=native in case you are doing a valgrind run

cc @VitalyFedyunin

[apaszke]

When and what do we build with -march=native? 😮

[ezyang]

Maybe it's not actually -march=native, but explicit requests for funny instructions, e.g., in our CPU kernels.

[apaszke]

That's possible. We should just make it possible to control the implementation selector via env vars, so you can disable those paths for debugging and testing.

[yf225]

I ran into this exact same issue when I was running https://github.com/pytorch/pytorch/blob/master/aten/tools/run_tests.sh#L24 with CUDA enabled, although there is no error if the CUDA path is avoided and THCRandom_init is not called. I wondered if this is Valgrind's incompatibility with CUDA?

[colesbury]

You can disable the AVX and AVX2 kernels by setting both environment variables ATEN_DISABLE_AVX2=1 ATEN_DISABLE_AVX=1.

But that's NOT the issue you're seeing. The issue is that GCC's libstdc++ uses RDRAND for std::random_device on Linux. I suspect that's in the library and doesn't depend on any compiler flag we provide. (We're not compiling the relevant code with -march=...)

http://www.pcg-random.org/posts/cpps-random_device.html

On Linux, we could switch to reading from /dev/urandom instead of std::random_device.

[ezyang]

Upstream reports this bug is fixed https://bugs.kde.org/show_bug.cgi?id=353370 so I'm gonna assume that you can get a recent enough version valgrind to work aroudn this problem