https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525
--- Comment #17 from Jan Hubicka <hubicka at ucw dot cz> ---
> GNU extern inline is an extension, so is covered by whatever we define (or
> should have defined). We've never required that the out of line and inline
> definitions are the same or in any way similar (prototypes have to match
> obviously), though without always_inline it is a compiler's choice what it
> will
> pick, whether it decides to inline it or not. AFAIK __fortify_function are
> extern inline __attribute__((always_inline, gnu_inline, aritifical)), so at
> that point the compiler needs to do what it is told, if it is possible to
> inline at all, inline, period.
The problem here is situation where indirect calls are present to the
fortified wraper. This is usual issue with always_inline not really
having the meaning "this function will always be inlined" becuase
it may be called indirectly but also directly if indirect call was
optimized to direct call too late in the optimization queue. We never
promised anything in this direction.
The harder problem here is the situation where both fortify wrapper and
the real function iplementation ends up in one translation unit (at LTO
time) that is something not really used before though it could be done
using asm("symbol_name") trickery which would not work very reliably.
The question is how invasiave changes we want to deploy to solve this
scenario and to what degree we want to commit supporting this in future.
We may also simply drop all those functions after early inlining and not
even consider fortifying calls turned form indirect to direct calls at
LTO time. The question would be whether to do that for all gnu_inlines
(and thus reduce their ability to be inlined through indirect calls) or
be bit more fine grained.
