[LLVM 6.0] Unexpected request for libcall!

[dylanmckay]

Occurs whilst compiling core with LLVM 6.0.

Unexpected request for libcall!
UNREACHABLE executed at /home/dylan/projects/avr-rust/rust/src/llvm/lib/Target/AVR/AVRISelLowering.cpp:335!
fish: Process 7219, “/home/dylan/projects/avr-rust/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustc” “~/projects/avr-rust/rust/build/…” terminated by signal SIGABRT (Abort)

I can see it happening in this function

_ZN45_$LT$u128$u20$as$u20$lib..ops..arith..Rem$GT$3rem17hee2f2f42f52a1976E

It also happens with the division code too.

From gdb

(gdb) print VT
$5 = {V = {SimpleTy = llvm::MVT::SimpleValueType::i128}, LLVMTy = 0x0}

It appears this is happening because the backend doesn't support i128 bit division.

[brainlag]

The rtlib functions for 128-Bit integers are defined so we just use these even when 128-Bit support doesn't make a lot of sense for AVR.

https://gist.github.com/brainlag/a14b2ba7ce52db1788712bfea2b699df

[shepmaster]

even when 128-Bit support doesn't make a lot of sense for AVR.

I agree with this viewpoint. For example, &Box<T> basically never makes sense in Rust, but it's still allowed. There's a line between where the language guides you and what makes sense for users to have knowledge about. I'd rather allow users to use a random crate that happens to use 128-bit integers.

[dylanmckay]

Thanks for the patch @brainlag, looks good to me, I will upstream it!

With regards to attribution, would you prefer me to use your GitHub handle or your real name (which I do not know) in the Patch by line in the commit message?

[brainlag]

I added my real name to my git profile.

[dylanmckay]

Committed to LLVM upstream in r327814.

We should be able to cherry-pick this commit into the LLVM 6.0 fork.

[leo60228]

So I should be able to fix this just by cherry-picking and possibly fixing merge conflicts?

[shepmaster]

We've recently upgraded to LLVM 8 🎉 I'm going to close any bug that is reported against an older version of LLVM. If you are still having this issue with the LLVM-8 based code, please ping me and I can reopen the issue!