Repository navigation
powerpc-unknown-linux-gnu fails to compile simple crates #50960
Description
Activity
- addedA-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.O-PowerPCTarget: PowerPC processorsTarget: PowerPC processorsC-bugCategory: This is a bug.Category: This is a bug.
on May 22, 2018 - addedT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.Performance or correctness regression from stable to beta.
on May 22, 2018 @lu-zero think you can possibly bisect to find the source of the problem? The cargo-bisect-rustc tool may help:
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 :)
I used
cargo-bisect-rustcas testcase.nightly-2018-01-13managed to build most of its dependencies and fail atnum_cpus.Expected no forward declarations! !382 = <temporary!> !{} LLVM ERROR: Broken function found, compilation aborted! error: Could not compile `num_cpus`.rustc-1.25.0seems to work fine as well.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.
I gave @nikomatsakis access to the instance since I was unable to get a result less coarse than what I posted before.
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`.- changed the title
[-]nightly and beta fail to compile simple crates on powerpc-unknown-linux-gnu[/-][+]powerpc-unknown-linux-gnu fails to compile simple crates[/+]on May 30, 2018 110 remaining items
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:21I have to fix that manually first and then re-try.
@cuviper Yes, for some reason it took
randfrom 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.There is
configure --enable-vendorfor that, or[build] vendor = truedirectly inconfig.toml. But even if you don't use the vendored sources,src/Cargo.lockshould 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#L1746No, I've never used
rustup. But I'll make sure--enable-vendoris set.Turns out I'm an idiot. I put the cross-compiled
rustcdistribution 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.
I can confirm that on nightly,
rustcworks correctly onpowerpc-unknown-linux-gnuagain.This can be resolved as fixed and closed. Thanks everyone!
You tested with #54266 applied? Normally we would let that PR merge close the bug automatically.
No, I tested the nightly and confirmed that it works.
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.
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.
- added a commit that references this issue
on Sep 20, 2018
Example:
Additionally I cannot install stable on powerpc and powerpc64le due
rust-docbeing not available.