Issue with function alignment in const combined with is_null on platforms with function pointer value not agreeing with function alignment. #144661
Description
I tried this code:
Running on armv5te-unknown-linux-gnueabi (and probably any other arm target with #[instruction_set(arm::t32)], or something similar on targets which use thumb mode by default, like thumbv7neon-unknown-linux-gnueabihf).
#![feature(fn_align)]
// This also occurs if using `-Zmin-function-alignment=2` on the CLI instead of `#[rustc_align(2)]` on just `foo`.
#[rustc_align(2)]
#[instruction_set(arm::t32)]
fn foo() {}
// If the assert succeeds, make sure this is the same value that `dbg!` prints below.
const EXPECTED_ADDR: usize = 0x00408aed;
const FOO_PTR: *const () = unsafe { std::mem::transmute::<fn(), *const ()>(foo) };
const MAYBE_NULL: *const () = FOO_PTR.wrapping_byte_sub(EXPECTED_ADDR);
fn main() {
dbg!(FOO_PTR);
let is_expected_addr_const = const { MAYBE_NULL.is_null() };
let is_expected_addr = { MAYBE_NULL.is_null() };
assert_eq!(is_expected_addr_const, is_expected_addr);
println!("Hello, world!");
}I expected to see this happen: The assert_eq succeeds (or compilation fails): the same value should not be non-null at compile time and null at runtime.
Instead, this happened:
[src/main.rs:18:5] FOO_PTR = 0x00408aed
thread 'main' panicked at src/main.rs:21:5:
assertion `left == right` failed
left: false
right: true
note: run with `RUST_BACKTRACE=1` environment variable to display a backtraceBecause foo is annotated #[rustc_align(2)], consteval believes that any odd offset from its address cannot be null. However, on ARM, all functions are aligned to at least 2, and the low bit of function pointers indicate which instruction set to use (0 = a32, 1 = t32 (thumb)). Since foo is #[instruction_set(arm::t32)], the low bit of a function pointer to it is thus odd at runtime, and thus subtracting the address it ends up at results in a null pointer.
ARM mode instructions are located on 4-byte boundaries. Thumb mode instructions are located on 2-byte boundaries. In the ARM architecture, bit 0 of a function pointer indicates the mode (ARM or Thumb) of the called function, rather than a memory location. When bit 0 = 1, Thumb mode is selected.
This also occurs if using -Zmin-function-alignment=2 on the CLI instead of #[rustc_align(2)] on just foo.
Tracking issue for fn_align: #140261
Proposed stabilization PR for -Cmin-function-alignment: #142824
Meta
rustc --version --verbose:
rustc 1.90.0-nightly (498ae9fed 2025-07-28)
binary: rustc
commit-hash: 498ae9fed2e7d90821d70a048f3770f91af08957
commit-date: 2025-07-28
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.8
I think the most "principled" solution for this would be for consteval to know about ARM (and maybe any other platform)'s function aligning/pointer tagging, so that FOO_PTR will be at offset 1 from the align-2 allocation for foo in consteval, and any arm::a32 function's function pointer would be at offset 0 from a its 4-byte-aligned allocation.
As a simpler workaround, maybe consteval could just make all function allocations be align-1 for consteval purposes, even if they have a higher alignment?
@rustbot label +A-const-eval +requires-nightly