Skip to content

rustc -O doesn't work on ARM #10192

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
chris-morgan opened this issue Oct 31, 2013 · 3 comments
Closed

rustc -O doesn't work on ARM #10192

chris-morgan opened this issue Oct 31, 2013 · 3 comments
Labels
O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state

Comments

@chris-morgan
Copy link
Member

Steps to reproduce:

  1. Take a build of rustc for ARM (specifically, gnueabi; gnueabihf is untested and may or may not exhibit this problem). Luqman has one you can use at http://luqman.ca/rust-builds/.
  2. Attempt to compile something with optimisations, e.g. echo 'fn main(){}' | rustc - -O.

This fails altogether:

Stack dump:
0.      Running pass 'Function Pass Manager' on module 'rust_out.rc'.
1.      Running pass 'Machine Common Subexpression Elimination' on function '@main'
Segmentation fault

A more complex example is building chris-morgan/rust-http@e909dfb; in this case it fails in a different way:

rustc: /scratch/laden/rust/src/llvm/include/llvm/ADT/ScopedHashTable.h:238: llvm::ScopedHashTableScope<K, V, KInfo, AllocatorTy>::~ScopedHashTableScope() [with K = llvm::Value*, V = std::pair<llvm::Value*, unsigned int>, KInfo = llvm::DenseMapInfo<llvm::Value*>, AllocatorTy = llvm::RecyclingAllocator<llvm::BumpPtrAllocator, llvm::ScopedHashTableVal<llvm::Value*, std::pair<llvm::Value*, unsigned int> >, 20u, 4u>]: Assertion `HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry &&"Scope imbalance!"' failed.
Stack dump:
0.      Running pass 'Early CSE' on function '@"_ZN6client7request13RequestWriter3new18url_to_socket_addr19h3ff5b73b6544aal7ag11v0.1$x2dpreE"'
Aborted

I believe these are LLVM bugs rather than rustc bugs, but at the least Rust is triggering them. Should I be reporting them in LLVM?

@thestinger
Copy link
Contributor

@chris-morgan: Use rustc --emit-llvm to output LLVM bytecode, and then use bugpoint -simplify-cfg -early-cse from Rust's LLVM directory (in Release+Asserts/bin) on the bytecode file. It should narrow down small a test case.

@luqmana
Copy link
Member

luqmana commented Nov 3, 2013

So it turns out it was a problem with the gcc version I was using (Debian 4.4.6-14) miscompiling LLVM in some way. Switched to Debian 4.7.2-4 and it seems to work.

@luqmana luqmana closed this as completed Nov 3, 2013
@chris-morgan
Copy link
Member Author

This has turned out to be a false alarm caused by old software; @luqmana provided me with a new build using GCC 4.7 to build LLVM instead of GCC 4.4 and -O is now working. Yes, compilation of the http crate on my tablet can now take more than a minute instead of twenty seconds.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 12, 2023
Partially revert rust-lang#9701

This partially reverts rust-lang#9701 due to rust-lang#10134

r? `@flip1995`

changelog: None
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state
Projects
None yet
Development

No branches or pull requests

3 participants