compiler-rt's ARM implementation of udivsi3 seems... wrong?

[alexcrichton]

I updated the compiler-rt submodule in #172 which notably pulled in llvm-mirror/compiler-rt@2fb759f I believe. I merged #172 despite failing tests believing it was a weird nightly thing, but the integration PR also failed with weird errors.

I did some more investigation locally and found I could reproduce the error on #172 locally relatively easily. When forced the compiler-builtins crate to use the Rust implementation of the __udivsi3 intrinsic then the error went away. The only other change to happen to this file since we last updated compiler-rt is llvm-mirror/compiler-rt@2624197 llvm-mirror/compiler-rt@6b34053, which when cherry-picked didn't seem to fix the problem.

I'm going to send a PR to avoid usage of compiler-rt's implementation, but it's presumably faster than what we have in Rust, so this is a tracking issue for closing that perf gap.

[alexcrichton]

@japaric I think you're more familiar with ARM assembly than I am, mind double-checking me on this to make sure I'm not off the rails?

[alexcrichton]

I'll also note that I don't actually know what the error, if any, is in the udivsi3.S file. It may not actually have any errors! What I'm doing could may be hiding the error somewhere else...

[kennytm]

Would pulling in llvm-mirror/compiler-rt@6b34053 fix the issue?

[alexcrichton]

Oh that's actually the commit I meant to mention above, unfortunately pulling that in didn't fix it

[parched]

@alexcrichton I think I can fix this, how did you reproduce it locally?

[alexcrichton]

@parched I think it should suffice to revert alexcrichton@681aaa9 and then run ci/run-docker.sh arm-unknown-linux-gnueabi

[parched]

@alexcrichton Thanks, trying that I get to

...
+ cargo test --no-default-features --target arm-unknown-linux-gnueabi --features gen-tests mangled-names
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running /target/arm-unknown-linux-gnueabi/debug/deps/compiler_builtins-eb4701e69158fd89
/target/arm-unknown-linux-gnueabi/debug/deps/compiler_builtins-eb4701e69158fd89: 1: /target/arm-unknown-linux-gnueabi/debug/deps/compiler_builtins-eb4701e69158fd89: Syntax error: word unexpected (expecting ")")

Have you seen that before?

[alexcrichton]

@parched I believe that's related to Linux's support to run non-native binaries by hook them with something like a QEMU interpreter. You may need to do something like https://github.com/rust-lang-nursery/compiler-builtins/blob/238647af806470dc73e585c03682083931d29cd5/.travis.yml#L48-L49 on your host system.

[japaric]

@parched Alternatively you pass --no-run to Cargo to compile the test but not run it, and then manually run the binary using QEMU (qemu-arm target/..).

@alexcrichton That reminds me, now that Cargo has "runner" support we might be able to drop the qemu-user-static stuff and replace it with runner = "qemu-arm" in .cargo/config.

[alexcrichton]

Oh right yeah, that migh work great!

[parched]

Ok thanks guys, I originally tried with just qemu-arm but it complained about missing dynamic linker library or something. I've found though I just needed to pass it the directory of the libs in the cross toolchain with -L. I made a small fix for the problem but I've found there is a more general problem with the builtins on a Thumb-1 but not Thumb-2 capable CPU. This looks like it is addressing it though https://reviews.llvm.org/rL298713.

[parched]

@alexcrichton IMO for now we should just revert llvm-mirror/compiler-rt@2fb759f

[alexcrichton]

We could, yes, but ideally we'd get that upstream

[parched]

Fyi https://reviews.llvm.org/D31220 has been accepted upstream now

[alexcrichton]

Great! As soon as we upgrade we can switch and close out this issue