"LLVM ERROR: Not supported instr" on avr-unknown-gnu-atmega328 #400
Comments
|
Possibly related, but I have started seeing this behavior after updating my xtensa fork from 1.48 -> 1.49. I created an issue on the llvm fork's tracker but perhaps this is actually a Rust issue. |
|
I ran into this or closely related issue while trying to get https://github.com/avr-rust/blink to compile. What I have noticed is that it compiles with the nightlies of 2021-01-07 but not after that date. The only thing I noticed between 2021-01-08 is that the version of compiler-builtins got updated from v0.1.36 to v0.1.39. with nightly 2012-01-08 with nightly 2012-01-08 I hope this helps. |
|
If someone has the patience, I think it would help to bisect the exact commit of compiler-builtins which leads to this regression. I would assume this is a multi-layer problem: A change in compiler-builtins makes rustc emit instructions which the LLVM AVR backend cannot (yet?) lower correctly. |
|
I feel challenged to do However I have yet no clue how to tell cargo it should use the IJsblokje: Dank je wel voor de versie 0.1.36 werkt, v0.1.39 niet meer |
|
I think running |
|
What I found with tab completion: That lacks the target_triple What should I do make |
|
After running a git bisect, it looks like the commit which causes the issue is: And the last good commit is: Bisect was run using: The target config was from here: https://github.com/Rahix/avr-hal/blob/master/avr-specs/avr-atmega328p.json |
|
Nice work @catcatmu! I can't do it myself right now unfortunately, but maybe someone can generate the LLVM IR from before and after this commit? E.g. using cargo +nightly-2021-01-07 rustc -Z build-std=core --target boards/avr-atmega328p.json -- --emit=llvm-ir -o /path/to/output-directoryOtherwise I will try taking a look later this weekend. |
|
Tar of different llvm-ir output (minus the build libs) Folders:
Notes:
|
|
Thanks (I'm having a look at it to express more apprication then a simple thanks 😄 |
|
And I admit that I lack knowledge about what I'm looking at. |
|
Okay, I got closer ... A minimal reproducer ( source_filename = "compiler_builtins.27zd1rau-cgu.0"
target datalayout = "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8"
target triple = "avr-unknown-unknown"
declare dso_local fastcc { i128, i128 } @specialized_div_rem_u128(i128, i128) unnamed_addr addrspace(1) #0
define hidden i128 @__divmodti4(i128 %a, i128 %b, i128* %rem) unnamed_addr addrspace(1) #0 {
start:
%b_neg = icmp slt i128 %b, 0
%b2.0 = select i1 %b_neg, i128 0, i128 %b
%0 = tail call fastcc addrspace(1) { i128, i128 } @specialized_div_rem_u128(i128 undef, i128 %b2.0) #4
unreachable
}
attributes #0 = { "target-cpu"="atmega328" }
attributes #1 = { nounwind readnone speculatable willreturn }
attributes #2 = { cold noreturn nounwind }
attributes #3 = { nounwind willreturn }
attributes #4 = { nounwind }
!llvm.module.flags = !{!0}
!0 = !{i32 7, !"PIC Level", i32 2}This produces invalid assembly containing the This definitely needs to be fixed on LLVM side but I wonder if we could, in the meantime, disable |
Yes, that would be great |
|
The 128bit intrinsics need to be present to be able to link when not using LTO I think. |
My check on LLVM bugtracker ( https://bugs.llvm.org/buglist.cgi?quicksearch=AVR ) did return only 36 bugreports. None of them has Not supported instr in the title. I think I found a way to help. |
|
I have requested an account at the LLVM bugtracker. I have the minimal reproducer from Rahix Do I have a good backtrace? |
|
@stappersg, I do not think the backtrace is relevant here. The issue is much earlier in the code-gen (where |
@bjorn3, can you elaborate on this? So far my experience with missing intrinsics was that they would lead to a linker error if referenced but everything works fine otherwise. |
|
I may be possible that without LTO it isn't possible to remove the references. It may also be possible that it can will be removed just fine. |
|
Acknowledge on "I do not think the backtrace is relevant here." At https://acronyms.thefreedictionary.com/LTO I could not find a possible fit for |
|
LTO means link time optimization. It allows optimizations to see all code in an executable, rather than only in a single object file. |
|
Reported upstream as https://bugs.llvm.org/show_bug.cgi?id=48863 |
Due to a compiler regression [1], latest nightly builds of the compiler are currently broken. Instead, suggest using the last working build which was `nightly-2021-01-07`. This commit can hopefully be reverted once the compiler is fixed again. [1]: rust-lang/compiler-builtins#400 Ref: #124
|
Here's a bugfix, with a description of what was going on: https://reviews.llvm.org/D95664 Once it is reviewed and merged into LLVM, we can cherry-pick it into upstream Rust. |
|
Before I accepted responsibilities slash privileges on project AVR Rust I had "out-of-github-band" contact with Dylan. I'll contact him again. It will be something like
Regards /me Adding another @dylanmckay |
|
Great, thank you, let's hope for the best. |
|
Does anyone have any news to share on this? |
|
Hello, long time no see, heh. I haven't engaged that with much open source for the better part of the year as you notice, I didn't really plan it that way. Let's get this D114611 PR through eh? It looks really good, I will finish the review this week, I doubt I will ask for any extra changes than the ones I already have because I think it's probably functionally correct already Take care everybody. More updates surely to follow soon. |
|
For what it is worth, there is a custom Rust Toolchain for AVR. |
|
I switched to the |
|
@Dionysusnu If you're using the Rust (rust-lang.rust) extension instead of matklad.rust-analyzer, go into your settings and tell it to use the rust-analyzer backend instead of rls. |
Upgrade llvm-project (rustc + avr = lovelove back again!) See: rust-lang/llvm-project#139 tl;dr: - closes rust-lang#83633, - closes rust-lang#82104, - closes rust-lang#79889, - closes rust-lang/compiler-builtins#400. 🙂
|
This has been fixed in rust-lang/rust#96845 - @Amanieu, would you mind closing this bug? 🙂 |
|
Awesome work @Patryk27 ! Looks like this took a lot of effort, so thanks for pushing through this. Looking forward to digging up my little Arduino and playing with it again :) |
|
Indeed, fantastic stuff, thank you @Patryk27 ! I just compiled my Rust AVR OS using nightly instead of my custom-patched toolchain and first impressions are good - this is massive news. Really really appreciated, thanks again :). |
|
Great work @Patryk27! Finally closing this issue! |
I am experiencing a bug when trying to compile my application for Arduino Uno.
Probably, there's a regression somewhere.
Because, it used to work 1 month ago. CI: https://travis-ci.com/github/Rahix/avr-hal/builds/207260821
Original issue: Rahix/avr-hal#124
Output
With
--releaseand--verbose:Reproduction
Dockefile:docker build --tag=ard .Versions
The text was updated successfully, but these errors were encountered: