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.

[infinity0]

Thanks for the clarification. Indeed, both Fedora and Debian are using a less-patched LLVM 4.0 than Rust, and this is the first Rust version that uses 4.0. I'll go over the differences when I next have time and see if any patches are suggestive.

[cuviper]

I can still reproduce this, even with rust using its own LLVM 6, and it gets the exact same output!

------------------------------------------
stderr:
------------------------------------------
thread 'main' panicked at 'f64 -> i32 (i32x4(-1234567, 12345678, -123456792, 1234567936) != i32x4(-1234567, 12345678, -123456789, 1234567890))', /home/jistone/rust/src/test/run-pass/simd-intrinsic-generic-cast.rs:128:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

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

[cuviper]

It appears that LLVM is generating the fptosi like f64 -> f32 -> i32, which loses significant bits in the f32. e.g. we want 1234567890 = 0x499602d2, but we got 1234567936 = 0x49960300.

See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1562196
https://bugs.llvm.org/show_bug.cgi?id=38342

[programmerjake]

the linked llvm bug has been fixed quite a while ago, has this issue been resolved by that?

[cuviper]

Yeah, we should be good here.