Repository navigation
Functions still get personality function attached to them when landing pads are disabled #55039
Description
Compiling with -Cpanic=abort or -Zno-landing-pads should make associated personality functions entirely unnecessary, yet they still somehow end up getting attached to functions generated with the "current" CG.
Consider for example this function:
pub fn fails2(a: &mut u32, b: &mut u32) -> i32 {
::std::mem::swap(a, b);
2 + 2
}which when compiled (with or without optimisations) with -Cpanic=abort, will contain no personality functions in 1.27.1 but will contain them starting with 1.28.
1.27.1
define i32 @_ZN7example6fails217h8dd58cf9651f12a5E(i32* noalias nocapture dereferenceable(4) %a, i32* noalias nocapture dereferenceable(4) %b) unnamed_addr #0 !dbg !4 {
start:
%0 = load i32, i32* %a, align 1, !dbg !7, !alias.scope !30, !noalias !33
%1 = load i32, i32* %b, align 1, !dbg !35, !alias.scope !33, !noalias !30
store i32 %1, i32* %a, align 1, !dbg !35, !alias.scope !30, !noalias !33
store i32 %0, i32* %b, align 1, !dbg !36, !alias.scope !33, !noalias !30
ret i32 4, !dbg !37
}1.28
define i32 @_ZN7example6fails217h203cd5a0beec258bE(i32* noalias nocapture dereferenceable(4) %a, i32* noalias nocapture dereferenceable(4) %b) unnamed_addr #0 personality i32 (i32, i32, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*)* @rust_eh_personality !dbg !4 {
start:
%tmp.0.copyload.i.i.i = load i32, i32* %a, align 4, !dbg !7, !alias.scope !21, !noalias !24
%0 = load i32, i32* %b, align 4, !dbg !26, !alias.scope !24, !noalias !21
store i32 %0, i32* %a, align 4, !dbg !26, !alias.scope !21, !noalias !24
store i32 %tmp.0.copyload.i.i.i, i32* %b, align 4, !dbg !28, !alias.scope !24, !noalias !21
ret i32 4, !dbg !31
}This is technically a codegen regression, albeit very innocuous one.
Activity
Enselic commentedon Nov 24, 2023
-Zno-landing-padswas removed three years ago in #70175, so I think we can close this issue as obsolete?FWIW it looks like no personality function is present any longer, but I don't really know if this is a valid way to check it: