powerpc-unknown-linux-gnu fails to compile simple crates

[lu-zero]

Example:

Compiling rand v0.4.2
Expected no forward declarations!
!262 = <temporary!> !{}
scope points into the type hierarchy
!327 = !DILocation(line: 1, scope: !255)
scope points into the type hierarchy
!329 = distinct !DILexicalBlock(scope: !255, file: !256, line: 388, column: 8)
scope points into the type hierarchy
!346 = !DILocation(line: 388, scope: !255)
scope points into the type hierarchy
!351 = !DILocation(line: 404, scope: !255)
LLVM ERROR: Broken function found, compilation aborted!
error: Could not compile `rand`.

  nightly-powerpc-unknown-linux-gnu unchanged - rustc 1.28.0-nightly (cb20f68d0 2018-05-21)
  beta-powerpc-unknown-linux-gnu installed - rustc 1.27.0-beta.5 (84b5a46f8 2018-05-15)

Additionally I cannot install stable on powerpc and powerpc64le due rust-doc being not available.

[nikomatsakis]

@lu-zero think you can possibly bisect to find the source of the problem? The cargo-bisect-rustc tool may help:

https://github.com/rust-lang-nursery/cargo-bisect-rustc

[lu-zero]

rustc-1.24.0 seems working. Now I can build cargo-bisect-rustc and try.

If in the mean time you could unbreak 1.26.0 would be great btw :)

[lu-zero]

I used cargo-bisect-rustc as testcase.

nightly-2018-01-13 managed to build most of its dependencies and fail at num_cpus.

Expected no forward declarations!
!382 = <temporary!> !{}
LLVM ERROR: Broken function found, compilation aborted!
error: Could not compile `num_cpus`.

[lu-zero]

rustc-1.25.0 seems to work fine as well.

[Mark-Simulacrum]

I believe we're waiting on a bisection here to a nightly range or a specific PR. Given that we're T-3 weeks from release if that doesn't happen soon we'll want the bisection soon.

[lu-zero]

I gave @nikomatsakis access to the instance since I was unable to get a result less coarse than what I posted before.

[lu-zero]

Now rust-1.26.1 installs and fails as well:

Expected no forward declarations!
!335 = <temporary!> !{}
scope points into the type hierarchy
!340 = !DILocation(line: 1, scope: !332)
scope points into the type hierarchy
!345 = distinct !DILexicalBlock(scope: !332, file: !24, line: 1128, column: 8)
scope points into the type hierarchy
!406 = !DILocation(line: 1128, scope: !332)
scope points into the type hierarchy
!412 = !DILocation(line: 1191, scope: !332)
LLVM ERROR: Broken function found, compilation aborted!
error: Could not compile `version_check`.

[Mark-Simulacrum]

I'm assigning @nikomatsakis and nominating for compiler team. 1.26.1 did not contain any fixes for this issue so it's unsurprising that it continues to not work.

[nikomatsakis]

To be clear, I do have access to the machine, but I also have very little time at the moment to really take advantage of that and do investigation =) (powerpc is not a Tier 1 platform, so it's not clear how much time to allocate here.) That said, I would like it to work!

@lu-zero

nightly-2018-01-13 managed to build most of its dependencies and fail at num_cpus.

are you saying that the nightly builds prior to this worked great?

[lu-zero]

No, no nightly picked up by the bisect program worked. All failed in different ways.

[pnkfelix]

@lu-zero could you share access to your instance with me as well? I want to try to help with the bisection if I can.

[lu-zero]

Sure

[glaubitz]

I have tested @LionNatsu 's patch from the LLVM review site and I can confirm that Rust works again for me \o/. Great job!

[edelsohn]

@glaubitz Thanks for opening the LLVM buf and creating a patch. I'm glad the combined effort could track this down.

[glaubitz]

@edelsohn All credits go to @LionNatsu :)

[glaubitz]

Hmm, so while the LLVM bug was now fixed, rustc is now running into this problem on powerpc:

thread 'main' panicked at 'unexpected getrandom error: Invalid argument (os error 22)', vendor/rand/src/os.rs:130:21

https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=powerpc&ver=1.28.0%2Bdfsg1-3&stamp=1536680035&raw=0

Even rustc 1.24 doesn't work anymore. I have the impression that something external is causing this.

[LionNatsu]

@glaubitz Have you checked this message? I have already fixed this recently rust-random/rand#589, released at rand 0.4.3.
All versions of rand before 0.4.3 were using wrong system call number on PPC(32/64).

[glaubitz]

Aha! I haven't seen that. Thanks a lot for pointing me at that. You probably saved me lots of digging now ;).

[LionNatsu]

You're welcome :)

[cuviper]

All versions of rand before 0.4.3 were using wrong system call number on PPC(32/64).

FWIW, their #[cfg(target_arch = "powerpc")] only applies to PPC32. PPC64 uses target_arch = "powerpc64", for both big and little endian, so they've never even tried to use getrandom. I just opened rust-random/rand#608 for this.

[glaubitz]

Is it actually necessary to add other architectures like sparc64 there as well? I have just skimmed over the code, so I don't know whether the syscall definitions are necessary.

[cuviper]

It's not necessary -- getrandom didn't even exist until kernel 3.17, and Rust supports older targets than that. It will fall back on /dev/urandom instead, keeping a static File open.

[glaubitz]

Right, I completely forgot about the fact that getrandom is rather new. I'll send a few PRs to amend the other architectures then.

[cuviper]

The LLVM fix is now committed. The next step for Rust is to backport it onto rust-lang/llvm branch rust-llvm-release-8-0-0-v1 in a pull request. When that's merged, you can bump the submodule here, like I did in #54136, and mark it to fix this issue.

[LionNatsu]

I sent the PR just now. It may also fix #31302 and #41253, but I don't have that permission to close them.

[glaubitz]

Nightly is still suffering from the rand issue:

thread 'main' panicked at 'unexpected getrandom error: Invalid argument (os error 22)', /home/glaubitz/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.2/src/os.rs:130:21

I have to fix that manually first and then re-try.

[cuviper]

@glaubitz, rand was fixed in 0.4.3, and the compiler has been updated to that since #53567. But you appear to have something of your own built with 0.4.2, since the path is under your ~/.cargo/. In that case, that program will have the wrong NR_getrandom regardless of the compiler.

[glaubitz]

@cuviper Yes, for some reason it took rand from my home directory instead of the vendored one, despite the fact I downloaded a full nightly tarball and cross-built that on x86_64. Will try that again later today.

[cuviper]

There is configure --enable-vendor for that, or [build] vendor = true directly in config.toml. But even if you don't use the vendored sources, src/Cargo.lock should still direct you to rand 0.4.3.

Maybe it's actually the rustup shim getting in your way? If you also compiled that yourself, it looks like they're still locked on 0.4.2:
https://github.com/rust-lang-nursery/rustup.rs/blob/c3e4ce4c5e11a5557a080be9bf8f6ee9d2c87839/Cargo.lock#L1746

[glaubitz]

No, I've never used rustup. But I'll make sure --enable-vendor is set.

[glaubitz]

Turns out I'm an idiot. I put the cross-compiled rustc distribution under /root/ but for testing I picked the older, buggy one from /srv/debian/ -.-.

Testing now, looks good but let me wait for the build to finish.

[glaubitz]

I can confirm that on nightly, rustc works correctly on powerpc-unknown-linux-gnu again.

This can be resolved as fixed and closed. Thanks everyone!

[cuviper]

You tested with #54266 applied? Normally we would let that PR merge close the bug automatically.

[glaubitz]

No, I tested the nightly and confirmed that it works.

[cuviper]

Well, nightly doesn't have the fix yet, so I think you just got lucky that the bug didn't manifest. Meaning that the unwritten stack locations must have had "harmless" bytes in them already, this time.

[glaubitz]

That surprises me. Without the fix, I could barely compile anything on powerpc. It bailed out very early trying to build the compiler itself. The nightly, on the other hand, works completely fine.

But I just looked, nightly doesn't seem to have it. What are the odds.