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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf trippels at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||hubicka at gcc dot gnu.org

--- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Adding Honza to CC.

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

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez aldyh at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||aldyh at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org ---
I don't get it.  Do you think the error is incorrect?

A simplified testcase yields this:

reynosa:/dev/shm/trunk/gcc$ cat a.c
int __readlinkat_alias(void) __asm__(readlinkat);

inline __attribute__((__always_inline__)) 
int readlinkat() {
  return __readlinkat_alias();
}

int main() {
  return readlinkat();
}
reynosa:/dev/shm/trunk/gcc$ ./xgcc -B./ a.c  -flto -O -Wall 
a.c: In function 'readlinkat':
a.c:4:5: error: inlining failed in call to always_inline 'readlinkat':
recursive inlining
 int readlinkat() {
 ^
a.c:5:3: error: called from here
   return __readlinkat_alias();
   ^

But this seems correct to me.  The call to readlinkat() in main is inlined as a
call to __readlinkat_alias() [which is an alias to readlinkat()].  So yeah, it
will be recursive inlining.

Do you think the error is incorrect, or do you think the same error should
appear for -std=gnu99?

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

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Aldy Hernandez from comment #2)
 
 Do you think the error is incorrect, or do you think the same error should
 appear for -std=gnu99?


I think that erroring out is a bit drastic.
Or do you think this is a bug in glibc?

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

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org ---
I certainly don't think this is a GCC bug.  A function inlining itself is
nonsensical.

[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]

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.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf trippels at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-30
 CC||trippels at gcc dot gnu.org
  Known to work||4.7.3
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.0

--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 % cat test.i
long __readlinkat_alias() __asm__(readlinkat);
__inline __attribute__((__always_inline__)) 
long readlinkat(int p1, const char *p2, char *p3, unsigned long p4) {
  __readlinkat_alias();
}

int main() {
  long (*b)(int, const char *, char *, unsigned long) = readlinkat;
  return b(0, 0, 0, 0);
}

(4.7.3 is fine with -std=gnu99)
markus@x4 % /usr/x86_64-pc-linux-gnu/gcc-bin/4.7.3/gcc -std=gnu99 -flto -r
-nostdlib test.i -O2 -o /dev/null

(4.9.0 fails)
markus@x4 % gcc -std=gnu99 -flto -r -nostdlib test.i -O2 -o /dev/null
test.i: In function ‘main’:
test.i:3:6: error: inlining failed in call to always_inline ‘readlinkat’:
recursive inlining
 long readlinkat(int p1, const char *p2, char *p3, unsigned long p4) {
  ^
test.i:4:21: error: called from here
   __readlinkat_alias();
 ^
lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/gcc returned 1 exit status
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
markus@x4 % gcc -std=gnu99  -r -nostdlib test.i -O2 -o /dev/null
markus@x4 %