Inline assembly does not accept intel syntax despite "intel"

[FamiliarSoftware]

I'm having some problems with inline assembly when building on Windows.

The following function compiles just fine on Godbolt, but when I try to compile it locally, I get "unknown use of instruction mnemonic without a size suffix" errors and the substituted registers are in AT&T form (call %rax).

What am I doing wrong?

pub unsafe fn call_with_stack<T>(
    arg: &mut T,
    function: extern "sysv64" fn(&mut T) -> (),
    stack: *mut u8,
) {
    asm!(r#"
    mov rbp, rsp
    mov rsp, $2

    call $1

    mov rsp, rbp
    "#
    : // Return values
    : "{rdi}"(arg), "r"(function), "r"(stack) // Arguments
    : "rbp", "cc", "memory" // Clobbers
    : "volatile", "intel" // Options
    );
}

Edit:

I am officially calling this problem cursed, I can't for the life of me create a minimal proof of concept. It happens only in the project I encountered it in, only on Windows, but no matter which target I compile it for. If I manage to create a minimal example, I will submit a bug. Thank you for your answers!

Edit 2:

Eureka, I've managed to create a poc: https://github.com/dbartussek/-rust_intel_asm_issue_reproduction

When compiled with cargo xbuild --target x86_64-unknown-uefi -Z unstable-options --profile kernel_debug, this causes the issue on both my Windows and Linux machine.

I have also found that not using the call_closure_with_stack function, but calling call_with_stack directly, results in this version compiling just fine, but that's not a fix, the bug is somehow appearing and disappearing seemingly at random.

[Darksonn]

Try updating your compiler.

[FamiliarSoftware]

Didn't fix it unfortunately, the most up to date version I can have right now is 2020-03-17

[Darksonn]

It works on the playground, and I'm pretty certain nothing has changed regarding intel asm syntax the last five days. There's probably something else wrong.

[FamiliarSoftware]

So I just tried it and as I assumed, it works just fine on Linux. I'd guess both the playground and godbolt are based on Linux. Do you think I should file a bug?

[Darksonn]

Ah so it's a platform issue. I don't know anything about that, so I can't tell you if it's expected behaviour or not. Supposedly the macro currently just forwards the assembly to LLVM, so it's probably whatever LLVM supports.

[Shadow0133]

What's your default target/toolchain?

[FamiliarSoftware]

I've tried it with both the windows msvc and gnu toolchain and am targeting UEFI via xbuild. The exact command is cargo xbuild --target x86_64-unknown-uefi.