On Mon, Jan 27, 2020 at 06:53:51PM +0100, Jakub Jelinek wrote: > On Mon, Jan 27, 2020 at 06:49:23PM +0100, Stefan Schulze Frielinghaus wrote: > > some function calls trigger the stack-protector-strong although such > > calls are later on implemented via calls to internal functions. > > Consider the following example: > > > > long double > > rintl_wrapper (long double x) > > { > > return rintl (x); > > } > > > > On s390x a return value of type `long double` is passed via a return > > slot. Thus according to function `stack_protect_return_slot_p` a > > function call like `rintl (x)` triggers the stack-protector-strong since > > rintl is not an internal function. However, in a later stage, during > > `expand_call_stmt`, such a call is implemented via a call to an internal > > function. This means in the example, the call `rintl (x)` is expanded > > into an assembler instruction with register operands only. Thus this > > late time decision renders the usage of the stack protector superfluous. > > I doubt your predicate gives any guarantees that the builtin will be > expanded inline rather than a library call. Some builtins might be expanded > inline or as a library call depending on various options, or depending on > particular arguments etc.
My predicate is more or less just a copy of what happens in `expand_call_stmt` where we have decl = gimple_call_fndecl (stmt); if (gimple_call_lhs (stmt) && !gimple_has_side_effects (stmt) && (optimize || (decl && called_as_built_in (decl)))) { internal_fn ifn = replacement_internal_fn (stmt); if (ifn != IFN_LAST) { expand_internal_call (ifn, stmt); return; } } There a decision is made whether a call is implemented as a call to an internal function or not. Thus using the very same logic it should be possible to decide at an earlier stage that a call will be implemented as a call to an internal function. Since an internal function has no linkage, it is therefore guaranteed that it will be inlined. Do I miss something? Cheers, Stefan