Wrong cast of u16 to usize on aarch64

[fparat]

Hello,

A cast of a u16 value returned from a C function to a usize is invalid when enabling optimization.

I tried this code (with cargo flag --release):

#include <stdlib.h>
#include <stdint.h>
#include <stdio.h>

struct bloc {
    uint16_t a;
    uint16_t b;
    uint16_t c;
};

uint16_t c_read_value(void) {
    struct bloc *data = malloc(sizeof(struct bloc));
    data->a = rand() & 0xFFFF;
    data->b = rand() & 0xFFFF;
    data->c = rand() & 0xFFFF;

    printf("C struct: a = %u, b = %u, c = %u\n",
        (unsigned) data->a, (unsigned) data->b, (unsigned) data->c);
    printf("C function returns %u\n", (unsigned) data->b);

    return data->b; /* leak data */
}

//#![feature(bench_black_box)]

#[link(name = "bad")]
extern "C" {
    pub fn c_read_value() -> u16;
}

fn main() {
    let value = unsafe { c_read_value() };
    dbg!(value); // ok
    dbg!(value as usize); // nok
    dbg!(usize::from(value)); // nok
    dbg!((value as usize) & 0xFFFF); // nok

    //dbg!(std::hint::black_box(value) as usize); // ok
}

I expected to print the same value when casting to usize.

Instead, the value is wrong, the cast seems to "absorb" the neighboring bytes. Worse, I cannot even mask with & 0xFFFF!

C struct: a = 17767, b = 9158, c = 39017
C function returns 9158
[src/main.rs:10] value = 9158
[src/main.rs:11] value as usize = 846930886
[src/main.rs:12] usize::from(value) = 846930886
[src/main.rs:13] (value as usize) & 0xFFFF = 846930886

Using black_box with nightly on the value fixes the issue. I'd like to find a good workaround for stable though.

No issue in debug mode.

To reproduce, this repo can be used: https://github.com/fparat/badcast

Meta

Bug present on stable and nightly.
Found on Linux aarch64 (Jetson Nano). No issue found on amd64 or armv7.

rustc +nightly --version --verbose:

rustc 1.63.0-nightly (490324f7b 2022-05-26)
binary: rustc
commit-hash: 490324f7b29d5f1a1e063a563045d790091ed639
commit-date: 2022-05-26
host: aarch64-unknown-linux-gnu
release: 1.63.0-nightly
LLVM version: 14.0.4

Same issue with both gcc and clang for the C code

clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0

Backtrace: N.A.

[fparat]

I'd like to find a good workaround for stable though.

Criterion has stable-compatible implementation of black_box: https://docs.rs/criterion/0.3.5/src/criterion/lib.rs.html#172-178

[HeroicKatora]

This appears to be an ABI issue for u16 return values. (More investigation below). The LLVM IR in Rust expects a i16 zeroextended to the architecture width, but is returned a 16-bit value with unspecified additional bits. Of course it then removes any instruction masking bits it assumes to be 0 already.

  %value = tail call zeroext i16 @c_read_value(), !dbg !10

This is probably incorrect. EABI defines returning in terms of calling fn (T) and says

When an argument is assigned to a register, any unused bits in the register have unspecified value.

I can't find anything specific to masking/zero-extending for return values though.

---

The assembly of the original C-code does not zero-extend but instead expects the caller to mask bits. As produced by

• ARM64 gcc 7.5
• -O3

I've added stars for annotating the instruction sequence delivering the result. Note that there's no bitmasking in that sequence, this is only performed on w20. Since all printing on the C side use w20 this goes unnoticed on the printf doesn't indicate any incorrect value.

        bl      rand
        mov     w21, w0
*       bl      rand
        and     w20, w0, 65535
*       mov     w19, w0
        bl      rand
        and     w3, w0, 65535
        mov     w2, w20
        and     w1, w21, 65535
        adrp    x0, .LC0
        add     x0, x0, :lo12:.LC0
        bl      printf
        mov     w1, w20
        adrp    x0, .LC1
        add     x0, x0, :lo12:.LC1
        bl      printf
*       mov     w0, w19

On the Rust side the w0 result is never modified by any instruction as per llvm qualifier.

• rustc: 1.61
• -Copt-level=3 --edition 2021 --target=aarch64-unknown-linux-gnu

        bl      c_read_value
        adrp    x22, .L__unnamed_1
        adrp    x20, <&T as core::fmt::Display>::fmt
        mov     x8, sp
        add     x22, x22, :lo12:.L__unnamed_1
        add     x20, x20, :lo12:<&T as core::fmt::Display>::fmt
        adrp    x23, :got:_ZN4core3fmt3num3imp52_$LT$impl$u20$core..fmt..Display$u20$for$u20$u32$GT$3fmt17h78bd006cfbffcd0fE
        strh    w0, [sp]

[HeroicKatora]

cc: @jonas-schievink the bot seems to not be assigning anyone, could you verify the tags: A-codegen, I-unsound?

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-high +T-compiler

[Mark-Simulacrum]

Raising priority as this affects a tier 1 target and seems relatively easy to trigger.