https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
--- Comment #10 from Nick Desaulniers <ndesaulniers at google dot com> --- (In reply to Jakub Jelinek from comment #9) > I've said in that thread that I don't really like disabling the inlining, if > we wanted to make sure everything is stack protected, we'd need to disable > all the inlining no matter whether the attribute is there or not, because > inlining by definition removes the stack protector checks, it is only tested > on function boundaries, not on inline function boundaries. > The user has the option to add noinline when he wants. I'm not against reverting my recent change to LLVM's inlining behavior (https://reviews.llvm.org/D91816, and the follow up to the docs https://reviews.llvm.org/D93422). Would be less work to do for inlining decisions. In the kernel, we could introduce a macro that's "noinline_for_lto" or "noinline_due_to_stackprotectors" or such; this specific case only comes about due to LTO between TUs with -fstack-protector* and -fno-stack-protector and inlining between them. Though, I'm still concerned about local cases (forgetting LTO for a moment) where folks use __attribute__((no_stack_protector)) will basically have to remember to additionally use __attribute__((noinline)) lest they hit the same kind of bugs within a TU. LLVM's current behavior "helps" developers avoid such pitfalls; otherwise developers will have to be able to diagnose on their own when such a case arises such that it causes bugs.
