Change:
<del> Subproject commit fc10370ef7d91babf512c10505f8f2176bc8519d </del> <ins> Subproject commit 593484fc1596707406b0b0b45b97feb08d2a1bfc </ins>

Discussion:
When compiling the following minimal AVR template in --release mode, the compiler aborts with an LLVM error (This is an empty template with an empty main that does nothing.) In debug mode the build works correctly: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
I’ve got the same problem. I am building my software based upon the AVR template "avr-” which I called "avr-unknown-gnu-”. This file looks mostly identical to the existing atmega’s on the web : I tried to build my project (which is just empty) on the nightly and stable versions, but I get the same type of error:
This is caused by A fix is pending in LLVM, but not yet merged... In the meantime, you can use the compiler version:
sorry to reopen this older issue but I'm seeing the same issues. I've tried like 3 different versions of the rust compiler, plus the current (1.55) version, and they all have the exact same issue?
is the last working version as of now. We're still blocked on a fix landing in LLVM which is pending review (see the compiler-builtins issue linked above).
Is there any plan to resolve this issue?
They are working on fixing the underlying bug in LLVM -
Thanks for the update,
Thanks for fixing this bug! :)

The following code snippet should light the pin 13 LED when compiled for the atmega328 and run on an arduino. It does not. This is possibly related to , and potentially also avr-rust/rust-legacy-fork. I initially found this while trying to implement a , so it is not restricted to compiler-generated vtables - any function pointers which are stored in the data segment are affected. Attempting to simplify further (such as using a single function pointer) tends to end up with pointers which are passed entirely in code and never loaded from the data segment. These appear to be compiled correctly. Built + Flashed with: Stepping through the execution in simavr/gdb makes the failure obvious - the vtable contains the byte-address of the implementation function, but the instruction (and indeed the instruction pointer of the AVR in general) uses word-addresses. As can be seen from the GDB output, after loading the VTable entry the Z register (the combination of r30 and r31) contains "0x00A8", and execution jumps to "0x0150". The vtable should instead include "0x0054", which when treated as a word-address will jump to the expected "0x00A8".
For the sake of confirming expected behavior of vtables, I tested the following snippet in avr-gcc, which generates a manual vtable in the data segment: This emits pretty much what I would have expected, with the vtable containing 0x004B for a function which is at byte-address 0x0096: I have no idea if the version of clang on my
I was able to narrow this down a bit further. Building my example rust code as a static lib, I was able to inspect the relocations in the vtable. For my C code built by avr-gcc: It looks like the wrong relocation type is being selected for the vtable entries.
Followup 3: This is supposedly fixed by , which appears to have stalled. I can't find an actual issue on that's tracking this, though.
Committed D87631 upstream in llvm/llvm-project
llvm/llvm-project seems to fix it, although it's not worth cherry-picking it until lands, as currently we hit on the master build for the reproduction example on this issue.
has the llvm fix trickled into our LLVM fork yet?
Yeah, it's part of LLVM 13. The commit: