Bug 1563393

Same with my attempt to update to futures 0.1.21 -- only ppc64 fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=26127289

---- result_smoke stdout ----
	thread 'result_smoke' panicked at 'assertion failed: `(left == right)`
  left: `Err(2)`,
 right: `Ok(2)`', tests/support/mod.rs:26:5

I can reproduce this on F28, but not on F27 or EPEL7 using LLVM 5, which makes me think this is probably a regression in LLVM 6.  Upstream rustc 1.25.0 (with LLVM 6) also fails.

The prior rustc 1.24.1 was fine, both rawhide and upstream, but they were using LLVM 5.0 and 4.0, respectively.

This seems to be related to using multiple codegen units and ThinLTO.  With "-Ccodegen-units=1" it's fine, and so is "-Ccodegen-units=16 -Zthinlto=off".  But with the default "-Ccodegen-units=16" alone, the test fails.

To reproduce, use the 0.1 branch here:
https://github.com/rust-lang-nursery/futures-rs

Build and run normally as: cargo test --test all --release

With options: cargo rustc --test all --release -- -Ccodegen-units=1
then run the executable ./target/release/deps/all-*

Bisecting llvm between release_50 and release_60 found:

649870608ee53da0c86f688e27e87cb5c6b0e090 is the first bad commit
commit 649870608ee53da0c86f688e27e87cb5c6b0e090
Author: Nemanja Ivanovic <nemanja.i.ibm>
Date:   Fri Dec 29 12:22:27 2017 +0000

    [PowerPC] Fix for PR35688 - handle out-of-range values for r+r to r+i conversion

    Revision 320791 introduced a pass that transforms reg+reg instructions to
    reg+imm if they're fed by "load immediate". However, it didn't
    handle out-of-range shifts correctly as reported in PR35688.
    This patch fixes that and therefore the PR.

    Furthermore, there was undefined behaviour in the patch where the RHS of an
    initialization expression was 32 bits and constant `1` was shifted left 32
    bits. This was fixed by ensuring the RHS is 64 bits just like the LHS.                                              

    Differential Revision: https://reviews.llvm.org/D41369


    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321551 91177308-0d34-0410-b5e6-96231b3b80d8

:040000 040000 306eeb39e948f043d7346c531fafdaa8257a985b 7833bc535f82feff5541cd27c535f2b43e18bb92 M      lib             
:040000 040000 2e78b86d47672038b2bbc9fe10d16f6992a0b0c1 5b2696a88a5536ca3c79a0fc6b644ecf0122ff1d M      test

Created attachment 1418287 [details]
IR and binaries from good and bad builds

The two builds come from these llvm commits:

futures-all-good: 2e7d056b717d7513b18472077996623a9e0d9e8d
futures-all-bad:  649870608ee53da0c86f688e27e87cb5c6b0e090

The IR looks identical, but I've included it here for completeness.  You'd probably need full rust libraries to reproduce the build though.

You can just run the binaries without arguments to see the failure.

Created attachment 1418383 [details]
proposed fix: convert RLDICLo using a 64-bit InVal too

Comparing the two binaries, I found a change like

 li      r6,2
 [...]
-rldicl. r7,r6,32,32
+andi.   r7,r6,2

r6 wasn't changed from 2, so the "rldicl." would have shifted and masked all the bits out, setting r7 to 0 and updating SO.  But the change to "andi." seems to think that the 32-bit shift was a no-op, essentially, leaving it as 2.

The fix in #c5 shows where I think it is incorrectly treating using a 32-bit value for RLDICLo.  Changing the value to 64-bit makes this same snippet of code now generate "andi.   r7,r6,0" -- and with this, the rust test passes!

Whoops.

Tom, can we backport this fix into Fedora?

The fix was in include in 6.0.1, so it should already be in rawhide.