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.
Jakub
