Bug 1837660

Summary: Miscompilation of rustc 1.43 leads to LTO failure
Product: [Fedora] Fedora Reporter: Josh Stone <jistone>
Component: llvmAssignee: Josh Stone <jistone>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 31CC: dmalcolm, jakub, jistone, scottt.tw, sean, sguelton, siddharth.kde, tstellar
Target Milestone: ---   
Target Release: ---   
Hardware: s390x   
OS: Unspecified   
Whiteboard:
Fixed In Version: llvm-9.0.1-6.fc31 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1840304 1840305 (view as bug list) Environment:
Last Closed: 2020-06-07 19:45:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1840304, 1840305    

Description Josh Stone 2020-05-19 18:49:53 UTC 
Description of problem:
Starting with Rust 1.43, we found that programs configured to build with full LTO were crashing rustc on s390x with a segmentation fault. It also happens with upstream Rust binaries. This is locally reproducible with a stage2 rustc, but stage1 (bootstrapped from 1.42) is fine.

Version-Release number of selected component (if applicable):
rust-1.43.0-1.fc31
llvm-9.0.1-5.fc31

How reproducible:
100%

Steps to Reproduce:
1. Rebuild an LTO rust package, like rust-afterburn.

Actual results:
SIGSEGV

Expected results:
Successful compilation.

Additional info:
The code which processes FatLTO modules was seeing a 0x1 data pointer for the name String. Ulrich Weigand (IBM) found a miscompilation in "Drop for Bomb" in src/librustc_codegen_ssa/back/write.rs, where it copied the wrong range into the newly Boxed value.

I bisected the problem in Rust to commit e82ec2315e5a, but the effect of that only simplified the LLVM IR. This did lead SROA to break up those memcpys more than they were before. Since F32 with LLVM 10 is working, I compared "opt" from 9 and 10 output and found a difference in shufflevector arguments. Bisecting LLVM led me to commit a9d6b0e5, "[InstCombine] Fix big-endian miscompile of (bitcast (zext/trunc (bitcast)))".

https://github.com/rust-lang/rust/commit/e82ec2315e5adb1c291c3702cd2ac1f46ecd0fcf
https://github.com/llvm/llvm-project/commit/a9d6b0e5444741d08ff1df7cf71d1559e7fefc1f

I have confirmed that backporting that change to LLVM 9 fixes the build for rust-afterburn, and the asm of that rustc code looks correct to me.
Comment 1 Josh Stone 2020-05-19 23:52:23 UTC 
f31: https://src.fedoraproject.org/rpms/llvm/pull-request/49
f30: https://src.fedoraproject.org/rpms/llvm/pull-request/50
Comment 2 Fedora Update System 2020-05-29 16:50:29 UTC 
FEDORA-2020-d8bba51d6a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d8bba51d6a
Comment 3 Fedora Update System 2020-05-30 02:03:51 UTC 
FEDORA-2020-d8bba51d6a has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d8bba51d6a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d8bba51d6a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 4 Fedora Update System 2020-06-07 19:45:23 UTC 
FEDORA-2020-d8bba51d6a has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.