[Bug lto/59626] [4.9 lto] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But the function doesn't inline itself, that is why it uses the asm alias and
GCC shouldn't be looking through that and merging the two decls because of
that.

Breaking this breaks pretty much all of glibc -D_FORTIFY_SOURCE, and there
really isn't any other way how to write it.

To show the reason for the inline:
__fortify_function __nonnull ((1, 2)) __wur ssize_t
__NTH (readlink (const char *__restrict __path, char *__restrict __buf,
                 size_t __len))
{
  if (__bos (__buf) != (size_t) -1)
    {
      if (!__builtin_constant_p (__len))
        return __readlink_chk (__path, __buf, __len, __bos (__buf));

      if ( __len > __bos (__buf))
        return __readlink_chk_warn (__path, __buf, __len, __bos (__buf));
    }
  return __readlink_alias (__path, __buf, __len);
}

The inline must be always_inline, because it is a security matter if it is
inlined or not, and we want it to expand as a call to __readlink_chk if
it needs runtime verification, otherwise as a call to the original function,
not inlined.  So, this is really a LTO/IPA bug.