s390x: "LLVM ERROR: Cannot select" when building libcore

[japaric]

Using system LLVM (Ubuntu's llvm-3.8-dev) I get this error when building libcore for s390x:

LLVM ERROR: Cannot select: 0x7f65689c91a0: ch = AtomicFence 0x7f6569696aa0, Constant:i64<7>, Constant:i64<1>
  0x7f656bf307d0: i64 = Constant<7>
  0x7f656bf306a0: i64 = Constant<1>
In function: _ZN4core4sync6atomic5fence17h7469b6a226f64f0fE

Meta

$ git rev-parse HEAD
ef9786ce0eac75bbe293d04dadc959bd481236a6

I'm going to try using rust-lang/llvm next. If that doesn't work, this issue would block #36006

cc @alexcrichton @brson

[alexcrichton]

:(

[japaric]

rust-lang/llvm works fine so far.

[infinity0]

In case it helps you debug, here are the commits that differ between Debian's LLVM (which is what Ubuntu's is based on) - plus patches in debian/patches:

# from https://github.com/rust-lang/llvm.git
# I added the tags for clarity
$ git log --graph --decorate=full --oneline llvm-debian/3.8.1-12~..rust-upstream/1.11.0
* 80ad955 (HEAD, tag: refs/tags/rust-upstream/1.11.0) [SimplifyCFG] Don't kill empty cleanuppads with multiple uses
* a73c41e [ArgumentPromotion] Propagate operand bundles to promoted call sites
* 7513452 Fix PR25339: ARM Constant Island
* 80fab33 [WinEH] Don't inline an 'unwinds to caller' cleanupret into funclets which locally unwind
* 25c7dc3 [AA] Hoist the logic to reformulate various AA queries in terms of other parts of the AA interface out of the base class of every single AA result object.
* 361ff3b [PM/AA] Actually wire the AAManager I built for the new pass manager into the new pass manager and fix the latent bugs there.
* 4f2b179 Add an "addUsedAAAnalyses" helper function
* 63f3a1b Add Rust's personality function to the list of known personality functions
* 3dcd2c8 Fix the freebsd building on Windows
* be89e4b Fix cross-compiling to FreeBSD
* deb2692 Don't compile usage of std::thread
* d16f119 [WinEH] Don't perform state stores in cleanups
* 9cc2b72 Add support for i1 compare operations to X86 FastISel, and ignore llvm.assume() intrinsics in the target-independent FastISel.
* 4d5a6d7 Fix compile on older clang/OSX versions
* cca16c0 Add some Rust allocation functions to TargetLibraryInfo + MemoryBuiltins
* de62574 Disable the PassInfo cache assertions to make the cache effective in builds with assertions enabld
* ad57503 (tag: refs/tags/llvm-debian/3.8.1-12) ReleaseNotes: tidy up

[japaric]

Thanks @infinity0. The list looks too short to me? Considering our fork is 3.9-ish and Debian's LLVM is 3.8.1. Is this log against our rust-llvm-2016-07-09 branch? That's what master is currently using.

Since codegen is working fine with our llvm fork, this doesn't block us from e.g. releasing std/rustc for this target. Should we close this then? If someone tries to build std for this target using system llvm then they'll run into this issue but there isn't much we can do -- they'll will have to backport some patch and patch their llvm to fix this (likely) llvm bug.

[infinity0]

@japaric sorry, the log compares the LLVM that rust 1.11.0 was released with, with what Debian has. It has moved onto 3.9 in the meantime, right. But then you could try building using llvm-3.9-dev instead of llvm-3.8-dev. I expect I'll have to do that for the next 1.12.0 stable release, but I haven't tried this myself yet.

[Mark-Simulacrum]

@infinity0 @japaric Could one of you test this today? I assume it's still a problem...

[japaric]

This is only a problem with LLVM 3.8 AFAIK. There are no problems with LLVM 3.9/4.0; proof of this is that we have a rust-std component available for s390x-unknown-linux-gnu. So if a distro wants to build std for s390x using LLVM 3.8 they will have to figure what patches to backport to make that work.

Closing as this not a problem on our side.