Repository navigation
Miscompilation with FFI bool return type on x86_64 #163911
Description
I'm observing erroneous behaviour around bool and FFI. A Rust function returning bool is producing values other than 0 or 1. I have a minimal reproduction here, which reproduces the issue on x86_64 Linux:
https://github.com/yeslogic/rust-bool-ffi
gcc and clang both reproduce.
For reference this is the C and Rust code:
#include <stdio.h>
#include <stdbool.h>
extern bool rust_fn_returning_bool(unsigned char);
int main(int argc, char **argv) {
bool ret = rust_fn_returning_bool(0x10);
printf("ret = %d\n", (int)ret);
return 0;
}#[unsafe(no_mangle)]
pub unsafe extern "C" fn rust_fn_returning_bool(flags: u8) -> bool {
(flags & 0x1) == 0x1
}When ./ffi is run I get the output: 16 instead of the expected 0 or 1.
rust_fn_returning_bool compiles to the following on 1.99.0:
0000000000000000 <rust_fn_returning_bool>:
0: 89 f8 movl %edi, %eax
2: c3 retq
And this on 1.98.0:
0000000000000000 <rust_fn_returning_bool>:
0: 89 f8 movl %edi, %eax
2: 24 01 andb $0x1, %al
4: c3 retq
That missing and appears to be the source of the issue.
Meta
rustc --version --verbose:
rustc 1.99.0 (b940084d7 2026-09-28)
binary: rustc
commit-hash: b940084d7eb6a299eb4bfeb8e34901bc051e7ac4
commit-date: 2026-09-28
host: x86_64-unknown-linux-gnu
release: 1.99.0
LLVM version: 23.1.1
The issue also occurs on nightly:
rustc 1.101.0-nightly (ea137335b 2026-10-05)
binary: rustc
commit-hash: ea137335b78829b4514bf1b4c16302f74fab8581
commit-date: 2026-10-05
host: x86_64-unknown-linux-gnu
release: 1.101.0-nightly
LLVM version: 23.1.3
I've only reproduced on x86_64. On aarch64 and loongarch64 the value is masked before returning.
Possibility related to:
Metadata
Metadata
Assignees
Labels
Area: Concerning the application binary interface (ABI)Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generationCategory: This is a bug.Issue: Correct Rust code lowers to incorrect machine codeCritical priorityRelevant to the compiler team, which will review and decide on the PR/issue.Performance or correctness regression from one stable version to another.
Activity
asquared31415 commentedon Oct 7, 2026
The LLVM IR emitted by rustc changed from
to
Which then causes LLVM to believe that it can return the higher bits unmodified. The test that was added to ensure that our bool handling was correct is not testing
x86_64-unknown-linux-gnu, it's testingx86_64-unknown-uefi, which for some reason has a different (correct) bool handling???@rustbot label -needs-triage +T-compiler +I-miscompile +A-llvm +A-ABI +I-prioritize
ds84182 commentedon Oct 7, 2026
llvm/llvm-project#12579 (comment)
The x86-64 psabi commit linked in the LLVM issue above has always said that bits 1-7 must be 0, but 8-N is undefined. So a bool return type must be zero extended to at least 8 bits.
asquared31415 commentedon Oct 7, 2026
The issue is #142389 removed zero extension of all scalar return types for x86_64, but #159317 uncovered the bug, since before then, there was code unconditionally zero extending it.
rustbot commentedon Oct 7, 2026
Assigning P-critical (discussion on Zulip).
25 remaining items
Move pinned Rust toolchain to 1.99.1
Move pinned Rust toolchain to 1.99.1
Move pinned Rust toolchain to 1.99.1
Move pinned Rust toolchain to 1.99.1
Move pinned Rust toolchain to 1.99.1
Move pinned Rust toolchain to 1.99.1
Move pinned Rust toolchain to 1.99.1
Move pinned Rust toolchain to 1.99.1
Move pinned Rust toolchain to 1.99.1
Move pinned Rust toolchain to 1.99.1
Rust 1.99.1 and MSRV 1.99 (cycle 2 dependency upkeep; never 1.99.0)
chore(toolchain): bump rust toolchain to 1.99.1 and nightly=2026-08-16 (
fix: pin Rust 1.98.1 (rapira-rs#201)
build: return to stable Rust
chore: rustc: 1.99.0 -> 1.99.1 (dfinity#11935)