Bit-shifts with dynamic RHSs are broken on AVR on large numbers (u64, u128, i64, i128)

[Patryk27]

Bit-shifts where the right-hand side is of statically unknown value yield spurious results - e.g.:

#[arduino_hal::entry]
fn main() -> ! {
    let dp = arduino_hal::Peripherals::take().unwrap();
    let pins = arduino_hal::pins!(dp);
    let mut serial = arduino_hal::default_serial!(dp, pins, 57600);

    let x = 1;
    let y = hint::black_box(1);
    let val: u64 = x << y;

    for b in val.to_le_bytes() {
        _ = ufmt::uwrite!(&mut serial, "{} ", b);
    }

    _ = ufmt::uwriteln!(&mut serial, "");

    loop {
        //
    }
}

... prints:

0 0 0 4 0 0 0 0

For u128 we get something even wilder:

1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0

Smaller types, such as u32, seem to behave correctly:

2 0 0 0

My rough guess lays in the vicinity of AVRShiftExpand::expand() or compiler-builtins (ABI mismatch?), but I'm yet to confirm it.

Note that this is mostly an informational report - I'll try to fix this bug;

[Patryk27]

kk, it's ABI mismatch - sprinkling #[avr_skip] to a few functions in compiler-builtins/src/int/shift.rs seems to help.

Somewhat unfortunately, avr-gcc doesn't provide 128-bit versions, so adding those #[avr_skip] breaks u128 shifts (undefined reference to '__ashlti3'); maybe we could somehow expose the correct ABI from LLVM's side, so that the 128-bit versions could be provided by compiler-builtins, we'll see.

[Patryk27]

Current rustc already contains the fix (it went together with compiler-builtins 0.1.86), so lemme close the issue 🙂