Failing build

[rhn]

Trying to build avr-rust breaks whenever I run make.
The submodule src/llvm is hardcoded to use the commit cebc0b4:

# make
[...]
Synchronizing submodule url for 'src/llvm'
[...]
# cd src/llvm; git checkout
(HEAD detached at cebc0b4)

This seems to correspond to the branch avr-rust, and produces a broken build, in which the shl instruction is not lowered properly:

CFG_LLVM_LINKAGE_FILE= LD_LIBRARY_PATH=/mnt/tempcache/AVR-rust/avr-rust-build/x86_64-unknown-linux-gnu/stage2/lib:$LD_LIBRARY_PATH   x86_64-unknown-linux-gnu/stage2/bin/rustc --cfg stage2  -O --cfg rtopt  --target=avr-atmel-none -C linker=avr-gcc -C ar=avr-ar  -C target-cpu=atmega328p -C prefer-dynamic -D warnings -L "avr-atmel-none/rt"     --out-dir x86_64-unknown-linux-gnu/stage2/lib/rustlib/avr-atmel-none/lib -C extra-filename=-a5fc0d6c ../avr-rust/src/libcore/lib.rs
LLVM ERROR: Cannot select: 0x7f616b009818: i8 = ##name## 0x7f616be53ce8, 0x7f616b5d3b88 [ORD=4] [ID=8]
  0x7f616be53ce8: i8,ch = CopyFromReg 0x7f616b840d10, 0x7f6170529ce8 [ORD=1] [ID=5]
    0x7f6170529ce8: i8 = Register %vreg0 [ID=1]
  0x7f616b5d3b88: i16 = and 0x7f616b00a158, 0x7f6171ba5720 [ORD=4] [ID=7]
    0x7f616b00a158: i16,ch = CopyFromReg 0x7f616b840d10, 0x7f6171bd8a90 [ORD=1] [ID=6]
      0x7f6171bd8a90: i16 = Register %vreg1 [ID=2]
    0x7f6171ba5720: i16 = Constant<7> [ID=4]
In function: _ZN3num8wrapping35Wrapping$LT$u8$GT$.Shl$LT$usize$GT$3shl20h8e8197c1e2abaa89d3aE

As a related question, how to make sure llvm does not revert to some other branch when I do make?

[dylanmckay]

libcore doesn't successfully build yet. I've been putting off fixing it until AVR-LLVM has been completely merged into LLVM trunk.

How to make sure llvm does not revert to some other branch when I do make?

From memory, I believe the way to do this is to set the default remote branch for origin to whatever branch you want to use.

[rhn]

I'm still going to try to make it work - fixes can be rebased or merged even afterwards. Which combo of branched is the most advanced right now?

I am going to follow shepmaster and use rust/rust@1447ce7 after merging with avr_support. Im not sure what was used for compiler-rt, so maybe the avr-rust master branch? Then for llvm it sounds like a good idea to use upstream with AVR changes merged with your pending patches (are they on avr-support branch?)... and avr-rust-support maybe? This confuses me the most.

After having that, I will try to make the build process work - expect pull requests :)

[dylanmckay]

I am going to follow shepmaster and use rust/rust@1447ce7

Sounds good :)

Im not sure what was used for compiler-rt

I believe I took the diff of avr-llvm/compiler-rt master..avr-support and applied it to whatever was at the tip of rust/src/compiler-rt.

Then for llvm it sounds like a good idea to use upstream with AVR changes merged with your pending patches

I believe it is best to avoid upstream, there are a few differences between the upstream AVR code and the avr-llvm/llvm repo (code review stuff mostly). As far as actual features go, I'm pretty certain that it's only code style stuff that's changed.

avr-rust-support was just master..avr-support applied on top of whatever LLVM commit Rust was at. There were a few merge conflicts but not too many.

I kinda followed the convention:

• avr-support tracks LLVM master
• avr-rust-support is the changes from avr-support but tracking Rust's specific LLVM version

After having that, I will try to make the build process work - expect pull requests :)

SGTM :)

[lberezy]

What's the status of this?

@dylanmckay I noticed that the line about further work on development being halted until upstream merging was complete was removed from the readme of avr-llvm, and http://reviews.llvm.org/p/dylanmckay/feed/ is showing no further updates.
Does this mean that upstream merging is complete and this issue can progress?

[shepmaster]

Libcore almost compiles as-is. The current known issues are:

• Expected either Y or Z register avr-llvm/llvm#213
• Data layout specification is incompatible with atomic loads and stores avr-llvm/llvm#214

Then there will be the process of ensuring that the generated code is correct.

[lberezy]

Hot damn, that is exciting.

How far off is the toolchain from having an average user compile and run some blinkenlights on an AVR device?

[shepmaster]

run some blinkenlights on an AVR device?

http://jakegoulding.com/blog/2016/01/24/rust-on-an-arduino-uno-part-3/

an average user

Depends on "average". I believe that most people who will be interested in this project at this point are capable of compiling LLVM and Rust and doing a bit of small hacking to fix the inevitable small issues. However, there's certainly a lot more that I'd like to provide to make it easier.

[dylanmckay]

Does this mean that upstream merging is complete and this issue can progress?

Merging isn't complete. I removed the line cause development didn't really halt.

[dylanmckay]

I have fixed both avr-llvm/llvm#213 and avr-llvm/llvm#214, and am currently updating to upstream master.

[shepmaster]

and am currently updating to upstream master.

I should probably push my partial changes. However, LLVM 4.0 changed more things! 😈

[shepmaster]

@dylanmckay here's my in-progress work

[dylanmckay]

I believe that this is no longer a problem.