Skip to content

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

New issue
New issue
Closed
Closed
powerpc-unknown-linux-gnu fails to compile simple crates#50960
Assignees
pnkfelix
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.O-PowerPCTarget: PowerPC processorsP-mediumMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

Description

@lu-zero
lu-zero
opened on May 22, 2018

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.

Activity

  1. kennytm
    added
    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
    O-PowerPCTarget: PowerPC processors
    C-bugCategory: This is a bug.
    on May 22, 2018
  2. emilyalbini
    added
    T-compilerRelevant 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.
    on May 22, 2018

  3. nikomatsakis commented on May 24, 2018

    @nikomatsakis
    nikomatsakis
    on May 24, 2018
    Contributor

    @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

  4. nikomatsakis
    added
    P-highHigh priority
    on May 24, 2018

  5. lu-zero commented on May 24, 2018

    @lu-zero
    lu-zero
    on May 24, 2018
    ContributorAuthor

    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 :)

  6. lu-zero commented on May 24, 2018

    @lu-zero
    lu-zero
    on May 24, 2018
    ContributorAuthor

    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`.

  7. lu-zero commented on May 24, 2018

    @lu-zero
    lu-zero
    on May 24, 2018
    ContributorAuthor

    rustc-1.25.0 seems to work fine as well.

  8. emilyalbini
    added this to the 1.27 milestone on May 27, 2018

  9. Mark-Simulacrum commented on May 29, 2018

    @Mark-Simulacrum
    Mark-Simulacrum
    on May 29, 2018
    Member

    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.

  10. lu-zero commented on May 29, 2018

    @lu-zero
    lu-zero
    on May 29, 2018
    ContributorAuthor

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

  11. lu-zero commented on May 30, 2018

    @lu-zero
    lu-zero
    on May 30, 2018
    ContributorAuthor

    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`.
  12. Mark-Simulacrum
    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

  13. 110 remaining items

  14. LionNatsu commented on Sep 15, 2018

    @LionNatsu
    LionNatsu
    on Sep 15, 2018
    Contributor

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

  15. glaubitz commented on Sep 15, 2018

    @glaubitz
    glaubitz
    on Sep 15, 2018
    Contributor

    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.

  16. cuviper commented on Sep 17, 2018

    @cuviper
    cuviper
    on Sep 17, 2018
    Member

    @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.

  17. glaubitz commented on Sep 17, 2018

    @glaubitz
    glaubitz
    on Sep 17, 2018
    Contributor

    @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.

  18. cuviper commented on Sep 17, 2018

    @cuviper
    cuviper
    on Sep 17, 2018
    Member

    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

  19. glaubitz commented on Sep 17, 2018

    @glaubitz
    glaubitz
    on Sep 17, 2018
    Contributor

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

  20. emilyalbini
    removed their assignment
    on Sep 17, 2018

  21. glaubitz commented on Sep 18, 2018

    @glaubitz
    glaubitz
    on Sep 18, 2018
    Contributor

    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.

  22. glaubitz commented on Sep 18, 2018

    @glaubitz
    glaubitz
    on Sep 18, 2018
    Contributor

    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!

  23. emilyalbini
    closed this as completedon Sep 18, 2018

  24. cuviper commented on Sep 18, 2018

    @cuviper
    cuviper
    on Sep 18, 2018
    Member

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

  25. glaubitz commented on Sep 18, 2018

    @glaubitz
    glaubitz
    on Sep 18, 2018
    Contributor

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

  26. cuviper commented on Sep 18, 2018

    @cuviper
    cuviper
    on Sep 18, 2018
    Member

    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.

  27. glaubitz commented on Sep 18, 2018

    @glaubitz
    glaubitz
    on Sep 18, 2018
    Contributor

    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.

  28. kennytm
    added a commit that references this issue on Sep 20, 2018

    Rollup merge of rust-lang#54266 - LionNatsu:master, r=nikomatsakis

    9c2dfb4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.O-PowerPCTarget: PowerPC processorsP-mediumMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions