TIL Rust "supports" #[export_name] with names of LLVM intrinsics! The following code compiles no problem
#[unsafe(export_name = "llvm.x86.rdtsc")]
fn foo() {
// ...
}(FYI llvm.x86.rdtsc is a very real LLVM intrinsic, used to read the timestamp counter value in x86)
which imo should be hard error anyway. But then if we combine this monstrosity with #[target_feature] (or -C target-feature for that matter), all the target feature data for that function is erased. This is possible even in stable Rust, both in debug and release profile.
Godbolt link https://godbolt.org/z/h7jdrsY54
Meta
Doing a naive bisect on Godbolt, I found out that this bug was introduced in 1.29.0!!
https://godbolt.org/z/8M9a4vs9Y
The solution is probably just disallow any #[export_name]'s that try to masquerade as LLVM intrinsics (i.e. name starts with llvm.), which will mean reverting to pre-1.29.0 behavior.
@rustbot label T-compiler
TIL Rust "supports"
#[export_name]with names of LLVM intrinsics! The following code compiles no problem(FYI
llvm.x86.rdtscis a very real LLVM intrinsic, used to read the timestamp counter value in x86)which imo should be hard error anyway. But then if we combine this monstrosity with
#[target_feature](or-C target-featurefor that matter), all the target feature data for that function is erased. This is possible even in stable Rust, both in debug and release profile.Godbolt link https://godbolt.org/z/h7jdrsY54
Meta
Doing a naive bisect on Godbolt, I found out that this bug was introduced in
1.29.0!!https://godbolt.org/z/8M9a4vs9Y
The solution is probably just disallow any
#[export_name]'s that try to masquerade as LLVM intrinsics (i.e. name starts withllvm.), which will mean reverting to pre-1.29.0 behavior.@rustbot label T-compiler