1.19 powerpc64le run-pass test failures: simd-intrinsic-generic-cast

[infinity0]

On Debian:

------stderr------------------------------
thread 'main' panicked at 'f64 -> i32 (i32x4(-1234567, 12345678, -123456792, 1234567936) != i32x4(-1234567, 12345678, -123456789, 1234567890))', /<<BUILDDIR>>/rustc-1.19.0+dfsg3/src/test/run-pass/simd-intrinsic-generic-cast.rs:127
note: Run with `RUST_BACKTRACE=1` for a backtrace.

------------------------------------------

Not sure if this is related to #42778

[infinity0]

@TimNN do you think this could be rust-lang/llvm#72 ? We haven't patched our LLVM in Debian yet.

[TimNN]

@infinity0: I honestly have no idea. It doesn't look like, did you enable LLVM assertions in that build?

[infinity0]

I don't enable LLVM assertions on purpose and I guess they're not enabled by default.

The same test also failed on Fedora.

From IRC:

<markos> infinity0, I'm almost sure there is no support for VSX intrinsics for rust (yet) so it's natural for the test to fail
<markos> infinity0, what may be the case, is rust might have scalar fallback for simd code on engines that don't have actual support -so the code may compile and run albeit slower- however once the simd engine is enabled if it's incomplete, tests will fail
<markos> but I don't know exactly the case here

I guess if no-one pipes up I'll just ignore this test for the time being.

[infinity0]

@cuviper

[infinity0]

I re-ran simd-intrinsic-generic-cast with LD_LIBRARY_PATH set to a rebuilt LLVM (with rust-lang/llvm#72 applied) and the failure remained, so I think it's unrelated.

BTW this is technically a regression, this test passed on Debian and Fedora before with 1.18, although markos from Debian's IRC thinks it's not really a regression, see the above quoted comments for details.

Also the smallest-hello-world error I think now is unrelated, I will move that to another bug report once I have some more details about it.

[infinity0]

smallest-hello-world issue moved to #44683

[nagisa]

Presence or lack of VSX intrinsics in rust is irrelevant in this context, as the generated LLVM is calling regular fptosi <4 x double> %_ to <4 x i32>. This LLVM instruction is supposed to select proper instructions that execute this conversion.

If LLVM was upgraded in any way recently, that’s where the bug is happening. The code rustc generates appears to be exactly the same as I remember it being ages ago.