Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1840305 - Miscompilation of rustc 1.43 leads to LTO failure
Summary: Miscompilation of rustc 1.43 leads to LTO failure
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: DevTools
Classification: Red Hat
Component: llvm
Version: 2020.2
Hardware: s390x
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 2020.2
Assignee: Josh Stone
QA Contact: Miloš Prchlík
URL:
Whiteboard:
Depends On: 1837660
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-26 17:30 UTC by Josh Stone
Modified: 2020-07-09 08:58 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1837660
Environment:
Last Closed: 2020-07-09 08:58:27 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:2884 0 None None None 2020-07-09 08:58:32 UTC

Description Josh Stone 2020-05-26 17:30:26 UTC 
+++ This bug was initially created as a clone of Bug #1837660 +++

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.

--- Additional comment from Josh Stone on 2020-05-19 16:52:23 PDT ---

f31: https://src.fedoraproject.org/rpms/llvm/pull-request/49
f30: https://src.fedoraproject.org/rpms/llvm/pull-request/50
Comment 4 Miloš Prchlík 2020-06-16 10:16:02 UTC 
Verified with llvm-toolset-9.0-llvm-9.0.1-5.el7, the upstream patches to tests included with the patch are applied, the tests passed.
Comment 6 errata-xmlrpc 2020-07-09 08:58:27 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2884
Note You need to log in before you can comment on or make changes to this bug.