Closed campbellcole closed 1 year ago
This looks like a bug in LLVM, this error should be unreachable. What version of rustc are you using? There was a recent upgrade to LLVM 16 that was reverted.
if (!isa<ConstantSDNode>(N->getOperand(1))) {
// 32-bit shifts are converted to a loop in IR.
// This should be unreachable.
report_fatal_error("Expected a constant shift amount!");
}
I am using nightly 1.70:
❯ rustc --version
rustc 1.70.0-nightly (db0cbc48d 2023-03-26)
I will try using an older nightly version, and I'll edit this comment with the results.
Edit: I hadn't noticed this before but the example project demonstrated on that tutorial includes a rust-toolchain.toml
file. Using the specific nightly build defined in that file solved the problem. I will try a few more versions to see if I can gauge approximately where the issue is, but I probably won't go so far as to bisect the exact commit. Thanks for your help!
I am facing the same problem. @campbellcole which exact version did you switch to?
Might be fixed by #522.
That being said, I'm not able to duplicate this issue with the following compiler and the default generated project:
$ rustc +nightly -Vv
rustc 1.70.0-nightly (44f518058 2023-03-20)
binary: rustc
commit-hash: 44f5180584404d18058cbbf224c55255db4fdcbb
commit-date: 2023-03-20
host: x86_64-pc-windows-gnu
release: 1.70.0-nightly
LLVM version: 15.0.7
After programming, I have a working blinky.
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE
$ cargo generate --git https://github.com/Rahix/avr-hal-template.git
Unable to load config file: C:\Users\William\.cargo\cargo-generate.toml
Project Name : avr-shl
Generating template ...
✔ Which board do you use? · Arduino Uno
[ 1/19] Done: .cargo\config.toml
[ 2/19] Done: .cargo
[ 3/19] Done: .gitignore
[ 4/19] Done: Cargo.toml
[ 5/19] Done: LICENSE-APACHE
[ 6/19] Done: LICENSE-MIT
[ 7/19] Done: README.md
[ 8/19] Done: avr-specs\avr-atmega1280.json
[ 9/19] Done: avr-specs\avr-atmega168.json
[10/19] Done: avr-specs\avr-atmega2560.json
[11/19] Done: avr-specs\avr-atmega328p.json
[12/19] Done: avr-specs\avr-atmega32u4.json
[13/19] Done: avr-specs\avr-atmega48p.json
[14/19] Done: avr-specs\avr-attiny85.json
[15/19] Done: avr-specs\avr-attiny88.json
[16/19] Done: avr-specs
[17/19] Done: rust-toolchain.toml
[18/19] Done: src\main.rs
[19/19] Done: src
Moving generated files into: `C:\msys64\home\William\Projects\MCVE\avr-shl`...
Initializing a fresh Git repository
Done! New project created C:\msys64\home\William\Projects\MCVE\avr-shl
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE
$ cd avr-shl/
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE/avr-shl
$ rm rust-toolchain.toml
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE/avr-shl
$ cargo +nightly build
Compiling compiler_builtins v0.1.87
Compiling core v0.0.0 (C:\Users\William\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\core)
Compiling proc-macro2 v1.0.54
Compiling unicode-ident v1.0.8
Compiling quote v1.0.26
Compiling syn v1.0.109
Compiling rustversion v1.0.12
Compiling proc-macro-hack v0.5.20+deprecated
Compiling paste v1.0.12
Compiling avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=4c9c44c314eb061ee20556ef10d45dea36e75ee4#4c9c44c3)
Compiling ufmt-macros v0.2.0
Compiling avr-device-macros v0.5.0
Compiling rustc-std-workspace-core v1.99.0 (C:\Users\William\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\l
ibrary\rustc-std-workspace-core)
Compiling nb v1.1.0
Compiling void v1.0.2
Compiling cfg-if v1.0.0
Compiling vcell v0.1.3
Compiling bare-metal v1.0.0
Compiling ufmt-write v0.1.0
Compiling nb v0.1.3
Compiling avr-device v0.5.0
Compiling ufmt v0.1.2
Compiling embedded-hal v0.2.7
Compiling embedded-storage v0.2.0
Compiling cfg-if v0.1.10
Compiling panic-halt v0.2.0
Compiling atmega-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=4c9c44c314eb061ee20556ef10d45dea36e75ee4#4c9c44c3)
Compiling arduino-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=4c9c44c314eb061ee20556ef10d45dea36e75ee4#4c9c44c3)
Compiling avr-shl v0.1.0 (C:\msys64\home\William\Projects\MCVE\avr-shl)
Finished dev [optimized + debuginfo] target(s) in 32.00s
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE/avr-shl
$ avrdude -patmega328p -carduino -PCOM5 -b57600 -Uflash:w:target\\avr-atmega328p\\debug\\avr-shl.elf:e
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "target\avr-atmega328p\debug\avr-shl.elf"
avrdude.exe: writing flash (306 bytes):
Writing | ################################################## | 100% 0.21s
avrdude.exe: 306 bytes of flash written
avrdude.exe: verifying flash memory against target\avr-atmega328p\debug\avr-shl.elf:
Reading | ################################################## | 100% 0.19s
avrdude.exe: 306 bytes of flash verified
avrdude.exe done. Thank you.
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE/avr-shl
$
I just published a new version of compiler-builtins, can you try updating the version in rust-lang/rust to see if this fixes your problem?
I already am preparing a PR to upgrade compiler-builtins, so I'll test to see that this issue is fixed as well while I'm at it.
Updating to 0.1.91
does not fix the problem for AVR, I'm sorry to say :(.
william@xubuntu-dtrain:~/Projects/MCVE/avr-shl$ LD_LIBRARY_PATH=/home/william/Projects/toolchains/build-llvm-toolchain/build-llvm/lib/ cargo +msp430-fix build -Zbuild-std=core
Compiling compiler_builtins v0.1.91
Compiling core v0.0.0 (/home/william/Projects/toolchains/build-llvm-toolchain/build-rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/core)
Compiling proc-macro2 v1.0.54
Compiling quote v1.0.26
Compiling unicode-ident v1.0.8
Compiling syn v1.0.109
Compiling rustversion v1.0.12
Compiling proc-macro-hack v0.5.20+deprecated
Compiling paste v1.0.12
Compiling avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=4c9c44c314eb061ee20556ef10d45dea36e75ee4#4c9c44c3)
Compiling avr-device-macros v0.5.0
Compiling ufmt-macros v0.2.0
Compiling rustc-std-workspace-core v1.99.0 (/home/william/Projects/toolchains/build-llvm-toolchain/build-rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/rustc-std-workspace-core)
Compiling nb v1.1.0
LLVM ERROR: Expected a constant shift amount!
error: could not compile `compiler_builtins` (lib)
warning: build failed, waiting for other jobs to finish...
I'm sympathetic to the AVR Rust use case, so I went and did a bisect. This is indeed an LLVM issue. The commit that introduced the bug is https://github.com/llvm/llvm-project/commit/840d10a1d2c939016f387a041b0fbb3a9d592b17 cc: @aykevl
My sccache
cache is now ruined thanks to having to compile LLVM many times, so please keep it in your thoughts :P.
I am facing the same problem. @campbellcole which exact version did you switch to?
The most recent functional version I could find is 2023-03-24
. I haven't tried versions which are more recent than the latest at the time of making this issue.
Oops, I didn't expect that to happen but I have a patch that should fix this. It's not very small though.
@aykevl Is there any workaround that can be applied locally for the time being, or "just wait until you get your patch into upstream LLVM"? If the latter, could you link the relevant Phabricator page when you submit? I can probably take care of the cherry-picking part into Rust's copy of LLVM once your patch is upstream.
I have pushed my changes here: https://github.com/llvm/llvm-project/compare/main...aykevl:llvm-project:avr-shift-loop
Feel free to submit these to Phabricator on my behalf. I'm not currently working on the AVR backend (sorry!). The patches should be mostly ready for review, although the "subreg liveness" patch may need a bit of cleanup.
(Side note: I believe that while this issue now results in an assertion, previously it would result in emitting symbols like __ashlsi3
so that would potentially still be an issue).
Unfortunately, getting these patches into LLVM is not a time commitment I can currently undertake (not this month at least). Cherry-picking from Phabricator for Rust's version of LLVM is different, as I've done this several times in the past.
In comparison, I have no experience submitting patches to Phabricator. If the patches require cleanup, someone else who is familiar w/ the AVR backend will have to get these patches upstream for the time being (or someone will have to bring me up to speed on the AVR backend/LLVM in general).
building as release works for me in 1.71.0 (current nightly). when building normally i get the same error:
LLVM ERROR: Expected a constant shift amount!
error: could not compile `compiler_builtins` (lib)
building as release works for me in 1.71.0 (current nightly).
Still fails for me against atmega32u4
target, release and debug builds.
Does adding:
[profile.dev]
opt-level = "s"
lto = true
to Cargo.toml
fix your debug build?
I’ve already done that, without I run out of registers.
The defining difference between debug build failing and release build succeeding seems to be codegen-units = 1
. If I add that to the debug build it also succeeds.
Tested with rustc 1.71.0-nightly (18bfe5d8a 2023-05-14)
The defining difference between debug build failing and release build succeeding seems to be
codegen-units = 1
. If I add that to the debug build it also succeeds.
Probably because the code changed in a way that it doesn't hit the faulty code path. I'm pretty sure the bug can still occur with codegen-units = 1
, just that it might avoid this particular instance.
adding codegen-units = 1
to my dev build works, thanks
The defining difference between debug build failing and release build succeeding seems to be
codegen-units = 1
. If I add that to the debug build it also succeeds.Probably because the code changed in a way that it doesn't hit the faulty code path. I'm pretty sure the bug can still occur with
codegen-units = 1
, just that it might avoid this particular instance.
I think so too, but so far it seems to avoid this issue. I hope this helps someone more knowledgeable to find the issue and for the rest of us to get the code compiling.
But as you say no guarantees.
I hope this helps someone more knowledgeable to find the issue and for the rest of us to get the code compiling.
There is a fix, see my earlier comment here: https://github.com/rust-lang/compiler-builtins/issues/523#issuecomment-1500734938.
Thanks for the patch @aykevl, I'll try to review and submit it over the next few days 🙂
Okie, patch tested & submitted: https://reviews.llvm.org/D152059
Once it's merged, I'll take care of bumping Rust's llvm-project and let know back.
Looks like https://github.com/llvm/llvm-project/commit/ff75a2be34fd76350216c36b7ea4c3f338df6215 has landed but there's more diffs en route?
Yea, the most important revision (and hopefully the last one) is https://reviews.llvm.org/D153197 - I'll take another stab at it at Saturday / Sunday (to address the comment from benshi001).
Status: fixed on LLVM's side - will be solved when LLVM's version is bumped here (apparently soon ™️ ).
fwiw, this got fixed with https://github.com/rust-lang/rust/pull/114048 🙂
When compiling the default project generated with
cargo generate --git https://github.com/Rahix/avr-hal-template.git
(following this tutorial), an LLVM error arises:I have tried searching for this error online and have found zero mentions of it, even outside the context of Rust.
The
-vv
argument produces the following output (trimmed to only show relevant compilations):As you may have seen from the log files, I am using NixOS and I have a suspicion this is part of the problem. I have the appropriate toolchains installed, but I don't know if I've got them all:
Any pointers towards the cause of this issue would be greatly appreciated. Thank you for your time :smile: