Bug 1563393 - rust-futures: FTBFS in Fedora rawhide
Summary: rust-futures: FTBFS in Fedora rawhide
Alias: None
Product: Fedora
Classification: Fedora
Component: llvm
Version: rawhide
Hardware: ppc64
OS: Unspecified
Target Milestone: ---
Assignee: Tom Stellard
QA Contact: Fedora Extras Quality Assurance
URL: http://apps.fedoraproject.org/koschei...
Depends On:
TreeView+ depends on / blocked
Reported: 2018-04-03 20:17 UTC by Josh Stone
Modified: 2018-07-01 10:08 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-07-01 10:08:29 UTC
Type: Bug

Attachments (Terms of Use)
IR and binaries from good and bad builds (1020.36 KB, application/x-xz)
2018-04-06 19:58 UTC, Josh Stone
no flags Details
proposed fix: convert RLDICLo using a 64-bit InVal too (1.01 KB, patch)
2018-04-06 22:07 UTC, Josh Stone
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
LLVM 37039 0 None None None 2018-04-06 23:40:12 UTC

Description Josh Stone 2018-04-03 20:17:14 UTC
Description of problem:
Package rust-futures fails to build from source in Fedora rawhide.

Version-Release number of selected component (if applicable):

Steps to Reproduce:
koji build --scratch f29 rust-futures-0.1.19-1.fc29.src.rpm

Additional info:
This package is tracked by Koschei. See:

Comment 1 Josh Stone 2018-04-03 20:25:07 UTC
Same with my attempt to update to futures 0.1.21 -- only ppc64 fails:

---- 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.

Comment 2 Josh Stone 2018-04-03 22:37:44 UTC
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:

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-*

Comment 3 Josh Stone 2018-04-06 19:18:27 UTC
Bisecting llvm between release_50 and release_60 found:

649870608ee53da0c86f688e27e87cb5c6b0e090 is the first bad commit
commit 649870608ee53da0c86f688e27e87cb5c6b0e090
Author: Nemanja Ivanovic <nemanja.i.ibm@gmail.com>
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

Comment 4 Josh Stone 2018-04-06 19:58:24 UTC
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.

Comment 5 Josh Stone 2018-04-06 22:07:26 UTC
Created attachment 1418383 [details]
proposed fix: convert RLDICLo using a 64-bit InVal too

Comment 6 Josh Stone 2018-04-06 22:20:49 UTC
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!

Comment 7 Igor Gnatenko 2018-05-09 17:36:46 UTC

Comment 8 Igor Gnatenko 2018-06-29 11:56:07 UTC
Tom, can we backport this fix into Fedora?

Comment 9 Tom Stellard 2018-06-29 15:23:37 UTC
The fix was in include in 6.0.1, so it should already be in rawhide.

Note You need to log in before you can comment on or make changes to this bug.