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.
I'm performing the very same check in stack_protect_return_slot_p as
done in expand_call_stmt. In the latter we check whether a call to a
builtin function can be realized as a call to an internal function. My
understanding of internal functions is that they have no linkage and are
therefore guaranteed to be inlined. Do I miss something, or where do you
see a potential problem which I could try to investigate?
Cheers,
Stefan
