Skip to content

Many tests failing with "Couldn't compile the test" on 32-bit PowerPC with 1.49 beta #81334

New issue
New issue
Closed
#85807
Closed
Many tests failing with "Couldn't compile the test" on 32-bit PowerPC with 1.49 beta#81334
#85807
Labels
C-bugCategory: This is a bug.I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.O-PowerPCTarget: PowerPC processors

Description

@glaubitz
glaubitz
opened on Jan 24, 2021

Since 1.49 beta, many tests fail on 32-bit PowerPC with the error that the test could not be compiled:

running 1 test
test src/test/rustdoc/async-move-doctest.rs - (line 8) ... FAILED

failures:

---- src/test/rustdoc/async-move-doctest.rs - (line 8) stdout ----
Couldn't compile the test.

failures:
    src/test/rustdoc/async-move-doctest.rs - (line 8)

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

I have not bisected the issue yet.

Full log in: https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=powerpc&ver=1.49.0%7Ebeta.4%2Bdfsg1-1%7Eexp1&stamp=1611482142&raw=0

CC @jrtc27 @infinity0 @smaeul @mator

Activity

  1. glaubitz
    added
    C-bugCategory: This is a bug.
    on Jan 24, 2021

  2. bjorn3 commented on Jan 24, 2021

    @bjorn3
    bjorn3
    on Jan 24, 2021
    Member

    I am seeing a lot of signal 4 (SIGILL) errors in the build log.

  3. bjorn3
    added
    I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
    O-PowerPCTarget: PowerPC processors
    on Jan 24, 2021

  4. glaubitz commented on Jan 24, 2021

    @glaubitz
    glaubitz
    on Jan 24, 2021
    ContributorAuthor

    Ah, that reminds me of one bug in LLVM: https://bugs.llvm.org/show_bug.cgi?id=46683

    I'll check whether this one fixes it: llvm/llvm-project@a5d161c

  5. glaubitz commented on Jan 24, 2021

    @glaubitz
    glaubitz
    on Jan 24, 2021
    ContributorAuthor

    Debian's LLVM 11 package (llvm-toolchain-11) already contains the fix, so it can't be this.

    I'm trying to bisect this now in the Rust compiler itself but I just stumbled into the problem that a cross build no longer builds a full stage2 compiler with the std compiler which can be used on the target system, so I will first have to figure out what changed in Rust here.

  6. bjorn3 commented on Jan 24, 2021

    @bjorn3
    bjorn3
    on Jan 24, 2021
    Member

    You can pass --stage 2 to ./x.py. The default changed to --stage 1.

  7. glaubitz commented on Jan 24, 2021

    @glaubitz
    glaubitz
    on Jan 24, 2021
    ContributorAuthor

    You can pass --stage 2 to ./x.py. The default changed to --stage 1.

    Thanks, that's what I guessed already, I just couldn't find the change in the vast amount of other changes ;).

  8. bjorn3 commented on Jan 24, 2021

    @bjorn3
    bjorn3
    on Jan 24, 2021
    Member

    https://blog.rust-lang.org/inside-rust/2020/08/30/changes-to-x-py-defaults.html: #73964

  9. glaubitz commented on Apr 12, 2021

    @glaubitz
    glaubitz
    on Apr 12, 2021
    ContributorAuthor

    Just cross-compiled 1.50 and the issue is still there:

    (sid_powerpc-dchroot)glaubitz@perotto:~/rustc/rustc-1.50.0+dfsg1$ CARGO_PKG_HOMEPAGE='https://github.com/alexcrichton/cfg-if' CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=cfg-if CARGO_PKG_REPOSITORY='https://github.com/alexcrichton/cfg-if' CARGO_PKG_VERSION=0.1.10 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=10 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/home/glaubitz/rustc/rustc-1.50.0+dfsg1/build/bootstrap/debug/deps:/home/glaubitz/tmp/usr/local/lib:' /home/glaubitz/tmp/usr/local/bin/rustc --crate-name cfg_if --edition=2018 /home/glaubitz/rustc/rustc-1.50.0+dfsg1/vendor/cfg-if-0.1.10/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=144fa4f9a0a129e5 -C extra-filename=-144fa4f9a0a129e5 --out-dir /home/glaubitz/rustc/rustc-1.50.0+dfsg1/build/bootstrap/debug/deps -L dependency=/home/glaubitz/rustc/rustc-1.50.0+dfsg1/build/bootstrap/debug/deps --cap-lints warn -Cdebuginfo=2 -C linker=powerpc-linux-gnu-gcc -Wrust_2018_idioms -Wunused_lifetimes -Dwarnings
{"artifact":"/home/glaubitz/rustc/rustc-1.50.0+dfsg1/build/bootstrap/debug/deps/cfg_if-144fa4f9a0a129e5.d","emit":"dep-info"}
Illegal instruction
(sid_powerpc-dchroot)glaubitz@perotto:~/rustc/rustc-1.50.0+dfsg1$

  10. glaubitz commented on Apr 12, 2021

    @glaubitz
    glaubitz
    on Apr 12, 2021
    ContributorAuthor

    I cannot get a sensible backtrace, unfortunately:

    (gdb) r --crate-name cfg_if --edition=2018 /home/glaubitz/rustc/rustc-1.50.0+dfsg1/vendor/cfg-if-0.1.10/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=144fa4f9a0a129e5 -C extra-filename=-144fa4f9a0a129e5 --out-dir /home/glaubitz/rustc/rustc-1.50.0+dfsg1/build/bootstrap/debug/deps -L dependency=/home/glaubitz/rustc/rustc-1.50.0+dfsg1/build/bootstrap/debug/deps --cap-lints warn -Cdebuginfo=2 -C linker=powerpc-linux-gnu-gcc -Wrust_2018_idioms -Wunused_lifetimes -Dwarnings
Starting program: /home/glaubitz/tmp/usr/local/bin/rustc --crate-name cfg_if --edition=2018 /home/glaubitz/rustc/rustc-1.50.0+dfsg1/vendor/cfg-if-0.1.10/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=144fa4f9a0a129e5 -C extra-filename=-144fa4f9a0a129e5 --out-dir /home/glaubitz/rustc/rustc-1.50.0+dfsg1/build/bootstrap/debug/deps -L dependency=/home/glaubitz/rustc/rustc-1.50.0+dfsg1/build/bootstrap/debug/deps --cap-lints warn -Cdebuginfo=2 -C linker=powerpc-linux-gnu-gcc -Wrust_2018_idioms -Wunused_lifetimes -Dwarnings
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
[New Thread 0xede3f0f0 (LWP 256221)]
{"artifact":"/home/glaubitz/rustc/rustc-1.50.0+dfsg1/build/bootstrap/debug/deps/cfg_if-144fa4f9a0a129e5.d","emit":"dep-info"}

Thread 2 "rustc" received signal SIGILL, Illegal instruction.
[Switching to Thread 0xede3f0f0 (LWP 256221)]
0xf4f59bbc in std::thread::local::fast::Key$LT$T$GT$::try_initialize::h23c87cba01958f05 ()
   from /home/glaubitz/tmp/usr/local/bin/../lib/librustc_driver-9cf50d6324ac9732.so
(gdb) bt
#0  0xf4f59bbc in std::thread::local::fast::Key$LT$T$GT$::try_initialize::h23c87cba01958f05 ()
   from /home/glaubitz/tmp/usr/local/bin/../lib/librustc_driver-9cf50d6324ac9732.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

  11. glaubitz commented on May 27, 2021

    @glaubitz
    glaubitz
    on May 27, 2021
    ContributorAuthor

    I'm bisecting this now. I think it might actually be a bug in the Rust compiler and not LLVM.

  12. glaubitz commented on May 29, 2021

    @glaubitz
    glaubitz
    on May 29, 2021
    ContributorAuthor

    git bisect has lead me to 0328e69:

    0328e69287b083af4d5d4b49cfc9175e9c82c88e is the first bad commit
commit 0328e69287b083af4d5d4b49cfc9175e9c82c88e
Author: Josh Triplett <[email protected]>
Date:   Sun Oct 25 22:11:20 2020 -0700

    Compile tools and internal libraries with the initial-exec TLS model
    
    This should produce more efficient code, with fewer calls to
    __tls_get_addr. The tradeoff is that libraries using it won't work with
    dlopen, but that shouldn't be a problem for tools or for our own
    internal libraries.
    
    Co-authored-by: Mark Rousskov <[email protected]>

 src/bootstrap/builder.rs | 8 ++++++++
 src/bootstrap/lib.rs     | 4 ++++
 2 files changed, 12 insertions(+)

  13. nagisa commented on May 29, 2021

    @nagisa
    nagisa
    on May 29, 2021
    Member

    At a first blush sounds like a limitation of the platform most likely (much like how it doesn't really support e.g. copy relocations all that well on PPC64) in which case a simple exclusion would make sense here.

  14. glaubitz commented on May 29, 2021

    @glaubitz
    glaubitz
    on May 29, 2021
    ContributorAuthor

    I can confirm that reverting that change fixes the Rust compiler on 32-bit PowerPC for me. So, I agree, it should just be disabled on this target.

  15. glaubitz commented on May 29, 2021

    @glaubitz
    glaubitz
    on May 29, 2021
    ContributorAuthor

    I can submit a simple patch either tonight or tomorrow some time.

  16. JohnTitor
    added a commit that references this issue on Aug 6, 2021

    Rollup merge of rust-lang#85807 - glaubitz:powerpc-disable-initial-ex…

    352ad62
  17. bors
    closed this as completedin 283619con Aug 6, 2021

  18. stefson commented on Apr 8, 2022

    @stefson
    stefson
    on Apr 8, 2022

    @glaubitz there are reports of powerpc little endian toolchains still hitting this bug, can you imagine to push a simple patch to include the case of little endian as well?

    example: https://github.com/void-ppc/void-packages/blob/master/srcpkgs/rust/patches/fix-ppc32.patch

  19. workingjubilee commented on Jul 22, 2022

    @workingjubilee
    workingjubilee
    on Jul 22, 2022
    Member

    ...Does LLVM, or any of our codegen backends for that matter, actually support PowerPC 32-bit LE targets? Do they really exist? I know PowerPCs are bi-endian, but I thought the endian-switch bit was an extension that 32-bit architectures didn't have to include.

    Well, I do know we don't actually support any ppc32le Rust targets. I don't think it would exactly be what one would call a "maintenance burden" to accept a patch that adds a mild fix to bootstrap for custom targets. But if people are really using this target, it might be better to submit an application to add it as a new tier 3 target, so we can at least be Formally Aware of it.

  20. jrtc27 commented on Jul 22, 2022

    @jrtc27
    jrtc27
    on Jul 22, 2022

    Yes. https://reviews.llvm.org/D93918

  21. workingjubilee commented on Jul 27, 2022

    @workingjubilee
    workingjubilee
    on Jul 27, 2022
    Member

    Fair enough!

    @stefson The patch you ask for is simple so if you send it in we probably would happily accept it, but the best way to make sure Void Linux's powerpcle-unknown-linux-* targets are accounted for in the future would be to go through the process of upstreaming them as a tier 3 target. For Tier 3 Platform Support, it isn't required that it works well or passes tests. In fact, it isn't even required to build. However, merely having such support in the codebase would help with letting us know which tuples are actually in use, and thus reduce the likelihood of accidentally stomping on them.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.O-PowerPCTarget: PowerPC processors

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions