Incorrect code generated for fastcall functions on i686-pc-windows-gnu

[ricobbe]

I tried this code:

#[repr(C)]
#[derive(Clone)]
struct S {
    x: u8,
    y: i32,
}

#[link(name = "extern", kind = "dylib")]
extern "fastcall" {
    fn fastcall_fn(a: S, b: i32);
}

fn main() {
    unsafe {
        fastcall_fn(S { x: 1, y: 2 }, 16);
    }
}

linked against the following C code (compiled to extern.dll):

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

struct S {
    uint8_t x;
    int32_t y;
};

__declspec(dllexport) void __fastcall fastcall_fn(struct S s, int i) {
    printf("fastcall_fn(S { x: %d, y: %d }, %d)\n", s.x, s.y, i);
    fflush(stdout);
}

I expected to see this output:

fastcall_fn(S { x: 1, y: 2 }, 16)

Instead, I got this output:

fastcall_fn(S { x: 1, y: 2 }, 18873345)
fastcall_fn(S { x: 1, y: 2 }, 29491201)

Meta

rustc --version --verbose:

rustc 1.58.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: i686-pc-windows-gnu
release: 1.58.0-dev
LLVM version: 13.0.0

Reproed against commit 7b3cd07 of master.

To reproduce, check out the fastcall-bug branch on my fork of rustc; the reproduction case is in src/test/run-make/fastcall-bug.

[ricobbe]

Oh, I forgot: it was suggested that I include my config.toml:

# Includes one of the default files in src/bootstrap/defaults
profile = "compiler"
changelog-seen = 2

[build]
build = "i686-pc-windows-gnu"

[rust]
debug-logging = true
verbose-tests = true

[llvm]
download-ci-llvm = true

Also please note that rustc generates correct code for this case on i686-pc-windows-msvc (with the obvious change to config.toml).

[mati865]

I don't think it's Rustc issue but either LLVM or GCC. If I'd bet I'd say it's GCC.
I haven't tested your configuration but when I was working on raw-dylib I've got the same issue with GCC but with Clang it worked perfectly.

[ricobbe]

That makes sense. To be honest, I mostly wanted to make sure this issue is documented. I've got a test case that is currently disabled for unrelated reasons that trips over this bug, so I want to have an issue number that I can put into the comments when I disable the affected functions calls as part of re-enabling the larger test.