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

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

[nheghathivhistha at gmail dot com]

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

            Bug ID: 59626
           Summary: [4.9 lto] /usr/include/bits/unistd.h:173:1: error:
                    inlining failed in call to always_inline 'readlinkat':
                    recursive inlining
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nheghathivhistha at gmail dot com

Coreutils-8.22 program 'cp' cannot be compiled with trunk gcc 4.9.0 with -O2
-ggdb -pipe -flto:

CCLD     src/cp
/usr/include/bits/unistd.h: In function 'careadlinkat.constprop':
/usr/include/bits/unistd.h:173:1: error: inlining failed in call to
always_inline 'readlinkat': recursive inlining
 __NTH (readlinkat (int __fd, const char *__restrict __path,
 ^
/usr/include/bits/unistd.h:185:3: error: called from here
   return __readlinkat_alias (__fd, __path, __buf, __len);
   ^
make[3]: ***
[/var/tmp/portage/sys-apps/coreutils-8.22/temp/ccoTpm79.ltrans9.ltrans.o] Error
1
make[3]: *** Waiting for unfinished jobs....
lto-wrapper: make returned 2 exit status
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20131228/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Makefile:5419: recipe for target 'src/cp' failed

Gcc-4.8.2 fails with -flto too:

CCLD     src/cp
/usr/include/bits/unistd.h: In function 'careadlinkat.constprop.21':
/usr/include/bits/unistd.h:173:1: error: inlining failed in call to
always_inline 'readlinkat': recursive inlining
 __NTH (readlinkat (int __fd, const char *__restrict __path,
 ^
/usr/include/bits/unistd.h:185:3: error: called from here
   return __readlinkat_alias (__fd, __path, __buf, __len);
   ^
make[3]: ***
[/var/tmp/portage/sys-apps/coreutils-8.22/temp/cctZ031y.ltrans8.ltrans.o] Error
1
make[3]: *** Waiting for unfinished jobs....
lto-wrapper: make returned 2 exit status
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Makefile:5419: recipe for target 'src/cp' failed

Both versions are fine without -flto.

[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 %
>From gcc-bugs-return-438754-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 30 17:17:23 2013
Return-Path: <gcc-bugs-return-438754-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27132 invoked by alias); 30 Dec 2013 17:17:22 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27085 invoked by uid 48); 30 Dec 2013 17:17:19 -0000
From: "reichelt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59635] [c++1y] ICE with auto and ... as lambda parameter
Date: Mon, 30 Dec 2013 17:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: reichelt at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords cc cf_known_to_fail
Message-ID: <bug-59635-4-TPbSC1oeos@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59635-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59635-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg02409.txt.bz2
Content-length: 575

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY635

Volker Reichelt <reichelt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
                 CC|                            |abutcher at gcc dot gnu.org
      Known to fail|                            |4.9.0

--- Comment #1 from Volker Reichelt <reichelt at gcc dot gnu.org> ---
Adam, this looks like your domain, would you mind having a look?

[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

[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

[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.8/4.9 Regression] /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
----------------------------------------------------------------------------
           Keywords|                            |lto
           Priority|P3                          |P1
   Target Milestone|4.9.0                       |4.8.3
            Summary|[4.9 lto]                   |[4.8/4.9 Regression]
                   |/usr/include/bits/unistd.h: |/usr/include/bits/unistd.h:
                   |173:1: error: inlining      |173:1: error: inlining
                   |failed in call to           |failed in call to
                   |always_inline 'readlinkat': |always_inline 'readlinkat':
                   |recursive inlining          |recursive inlining

[Bug lto/59626] [4.8/4.9 Regression] /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
----------------------------------------------------------------------------
                 CC|                            |vhaisman at gmail dot com

--- Comment #7 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
*** Bug 56088 has been marked as a duplicate of this bug. ***

[Bug lto/59626] [4.8/4.9 Regression] /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
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look.

[Bug lto/59626] [4.8/4.9 Regression] /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
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|ASSIGNED                    |WAITING

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
We are merging the cgraph nodes for the function and the alias:

Merging nodes for readlinkat. Candidates:
readlinkat/0 (readlinkat) @0x7ffff66ba6f0
  Type: function
  Visibility: prevailing_def_ironly public
  next sharing asm name: 2
  References:
  Referring:
  Read from file: t.o
  Function flags: analyzed finalized
  Called by:
  Calls: *readlinkat/2 (1.00 per call)
*readlinkat/2 (__readlinkat_alias) @0x7ffff66ba940
  Type: function
  Visibility: external public
  previous sharing asm name: 0
  References:
  Referring:
  Read from file: t.o
  Function flags:
  Called by: main/1 (1.00 per call) readlinkat/0 (1.00 per call)
  Calls:
After resolution:
readlinkat/0 (readlinkat) @0x7ffff66ba6f0
  Type: function
  Visibility: prevailing_def_ironly public
  next sharing asm name: 2
  References:
  Referring:
  Read from file: t.o
  Function flags: analyzed finalized
  Called by:
  Calls: *readlinkat/2 (1.00 per call)
*readlinkat/2 (__readlinkat_alias) @0x7ffff66ba940
  Type: function
  Visibility: external public
  previous sharing asm name: 0
  References:
  Referring:
  Read from file: t.o
  Function flags:
  Called by: main/1 (1.00 per call) readlinkat/0 (1.00 per call)
  Calls:
...

Replacing cgraph node __readlinkat_alias/2 by readlinkat/0 for symbol
readlinkat
callgraph:

main/1 (main) @0x7ffff66ba818
  Type: function
  Visibility: force_output prevailing_def public
  References:
  Referring:
  Read from file: t.o
  Availability: available
  Function flags: analyzed finalized
  Called by:
  Calls: readlinkat/0 (1.00 per call)
readlinkat/0 (readlinkat) @0x7ffff66ba6f0
  Type: function
  Visibility: prevailing_def_ironly public
  References:
  Referring:
  Read from file: t.o
  Availability: available
  Function flags: analyzed finalized
  Called by: readlinkat/0 (1.00 per call) main/1 (1.00 per call)
  Calls: readlinkat/0 (1.00 per call)


And there is the optimization issue that we already get rid of the need
for the inline body during early inlining and thus we'd need to keep the
extern decl only.  And always-inline body never "prevails" (even though
we emit them eventually if inlining failed or somebody took its address -
something we maybe should change ...).  It works when using
extern inline __attribute__((always_inline,gnu_inline)) or extern inline
and not -std=c99.  So maybe that inline int readlinkat() {} _can_ prevail?

The glibc fortify wrappers use

extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) __attribute__ ((__artificial__)) void *
__attribute__ ((__nothrow__ , __leaf__)) memcpy (void *__restrict __dest, const
void *__restrict __src, size_t __len)

{
  return __builtin___memcpy_chk (__dest, __src, __len, __builtin_object_size
(__dest, 0));
}

and thus extern gnu inline always-inline which works fine.  So IMHO this
bug doesn't warrant P1 status.

Btw, it fails with 4.8 even with -O0 (with 4.9 -O0 works!?  Ah, because
we massaged the condition guarding the error ...).

Still the callgraph is wrong and we miscompile the testcase in 4.9 with -O0
(to an endless recursion).

In the testcase from comment #2 'readlinkat' is

 <function_decl 0x7ffff6d4a800 readlinkat
...
    addressable used public static autoinline decl_5 QI file t.c line 4 col 10
align 8 context <translation_unit_decl 0x7ffff6d6a000 D.1748> attributes
<tree_list 0x7ffff6d45938> initial <block 0x7ffff6d55910>

which makes it go to the LTO symbol table (where the linker plugin then
decides it prevails - which is already wrong).  When adding 'extern' to
the declaration we do _not_ output it in the LTO symbol table because
it isn't even in the symtab encoder (it's reclaimed).

So I'm not sure if the testcase is even valid (without -flto we behave
the same as gcc 4.9 with -O0 and -flto - we compile this to endless
recursion - and a self-recursive always-inline function is ok to being
diagnosed IMHO).

So - I'm inclined to close this as INVALID?  My glibc version always has
'extern' on the inlines.

So - please provide preprocessed source of the file that uses readlinkat
or provide complete compile options.

[Bug lto/59626] [4.8/4.9 Regression] /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
----------------------------------------------------------------------------
           Priority|P1                          |P2
                 CC|                            |rguenth at gcc dot gnu.org

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

[nheghathivhistha at gmail dot com]

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

--- Comment #10 from David Kredba <nheghathivhistha at gmail dot com> ---
There is preprocessed source in closed as duplicate of this error:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088.

I will attach one from program cp.

[Bug lto/59626] [4.8/4.9 Regression] /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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to David Kredba from comment #10)
> There is preprocessed source in closed as duplicate of this error:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088.
> 
> I will attach one from program cp.

The duplicate preprocessed source has correct wrappers:

extern int __vswprintf_alias (wchar_t *__restrict __s, size_t __n, __const
wchar_t *__restrict __fmt, __gnuc_va_list __ap) throw () __asm__ (""
"vswprintf")


                                     ;

extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__, __artificial__)) int
__attribute__ ((__leaf__)) vswprintf (wchar_t *__restrict __s, size_t __n,
__const wchar_t *__restrict __fmt, __gnuc_va_list __ap) throw ()

{
  if (__builtin_object_size (__s, 1 > 1) != (size_t) -1 || 1 > 1)
    return __vswprintf_chk (__s, __n, 1 - 1,
       __builtin_object_size (__s, 1 > 1) / sizeof (wchar_t), __fmt, __ap);
  return __vswprintf_alias (__s, __n, __fmt, __ap);
}

and it works for me.

[Bug lto/59626] [4.8/4.9 Regression] /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 #12 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Created attachment 32210
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32210&action=edit
Unreduced testcase

Here's the unreduced testcase:

markus@x4 coreutils % gcc -std=gnu99 -flto -O2 cp.i copy.i areadlinkat.i
careadlinkat.i linkat.i
/usr/include/bits/unistd.h: In function ‘careadlinkat.constprop’:
/usr/include/bits/unistd.h:173:42: error: inlining failed in call to
always_inline ‘readlinkat’: recursive inlining
 __NTH (readlinkat (int __fd, const char *__restrict __path,
                                          ^
/usr/include/bits/unistd.h:185:3: error: called from here
   return __readlinkat_alias (__fd, __path, __buf, __len);
   ^
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
>From gcc-bugs-return-444771-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Feb 25 12:09:58 2014
Return-Path: <gcc-bugs-return-444771-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17170 invoked by alias); 25 Feb 2014 12:09:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17149 invoked by uid 48); 25 Feb 2014 12:09:53 -0000
From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60337] s390: Function arguments are not aligned
Date: Tue, 25 Feb 2014 12:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ABI, diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vogt at linux dot vnet.ibm.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60337-4-s7LOizYpgZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60337-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60337-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg02528.txt.bz2
Content-length: 852

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`337

--- Comment #4 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
> It's the same on x86 I suppose

Well, the test program works fine on my amd64 box i.e. the alignment is
correct in all three functions (I guess foo() needs more int args to force
"a" onto the stack), and from a casual glance at libffi I assume that
there is support for that too.

> I don't see in your testcase where "Also, a parameter that is passed in
> a register and then copied to the stack is not aligned." happens.

In the call to baz().  l is passed in a register and then copied to the
stack so that the address can be taken to be passed to printf()
(verified by looking at the assembler output).  Gcc doesn't honour the
alignment when moving the register contents onto the stack, it puts the
value just at 160(%r15).

[Bug lto/59626] [4.8/4.9 Regression] /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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #12)
> Created attachment 32210 [details]
> Unreduced testcase
> 
> Here's the unreduced testcase:
> 
> markus@x4 coreutils % gcc -std=gnu99 -flto -O2 cp.i copy.i areadlinkat.i
> careadlinkat.i linkat.i
> /usr/include/bits/unistd.h: In function ‘careadlinkat.constprop’:
> /usr/include/bits/unistd.h:173:42: error: inlining failed in call to
> always_inline ‘readlinkat’: recursive inlining
>  __NTH (readlinkat (int __fd, const char *__restrict __path,
>                                           ^
> /usr/include/bits/unistd.h:185:3: error: called from here
>    return __readlinkat_alias (__fd, __path, __buf, __len);
>    ^
> 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

Confirmed with that testcase.  (it doesn't link though - files are missing?)

cgraph merging does

Replacing cgraph node __readlinkat_alias/183 by readlinkat/181 for symbol
readlinkat

I think it's caused by IPA-CP which does

Evaluating opportunities for careadlinkat/187.
 - Creating a specialized node of careadlinkat/187 for all known contexts.
    replacing param fd with const -100
    replacing param buffer with const 0B
    replacing param buffer_size with const 0
    replacing param alloc with const 0B
    replacing param preadlinkat with const readlinkat
                Accounting size:45.00, time:231.11 on predicate:(true)
                Accounting size:3.00, time:2.00 on new predicate:(not inlined)
     the new node is careadlinkat.constprop.5/106.
ipa-prop: Discovered an indirect call to a known target
(careadlinkat.constprop.5/106 -> readlinkat/181), for stmt with uid 2

and then IPA inlining decides

Considering readlinkat with 27 size
   Estimating body: readlinkat/181
   Known to be false: not inlined
   size:24 time:19
 to be inlined into careadlinkat.constprop.5 in unknown:-1
 Estimated growth after inlined into all is +36 insns.
 Estimated badness is -2147483648, frequency 16.39.
                Accounting size:4.00, time:55.21 on predicate:(true)
Processing frequency readlinkat
  Called by careadlinkat.constprop.5 that is normal or hot
  enqueuing call readlinkat/130 -> readlinkat/181, badness -2147483648

(!)

So it is IPA inlining that follows aliases bogously.  The alias target
is _not_ the non-prevailing extern inline function.

OTOH coreutils is walking on shaking grounds (or glibc is) as it takes
the address of an always-inline function.  That address-taking should
probably refer to an extern decl instead (and we are wrong to identify
it with the readlinkat variant with body at LTO time).

Btw, the LTO symbol table looks good to me.  Still somehow the inline
body prevails ... :/

  /* If there's not a prevailing symbol yet it's an external reference.
     Happens a lot during ltrans.  Choose the first symbol with a
     cgraph or a varpool node.  */
  if (!prevailing)
    {
...
      /* For variables prefer the non-builtin if one is available.  */
      else if (TREE_CODE (prevailing->decl) == FUNCTION_DECL)
        {
          for (e = first; e; e = e->next_sharing_asm_name)
            if (TREE_CODE (e->decl) == FUNCTION_DECL
                && !DECL_BUILT_IN (e->decl)
                && lto_symtab_symbol_p (e))
              {
                prevailing = e;
                break;
              }

Now it is readlinkat

$22 = {type = SYMTAB_FUNCTION, resolution = LDPR_RESOLVED_DYN, definition = 1, 
  alias = 0, weakref = 0, cpp_implicit_alias = 0, analyzed = 1, 
  externally_visible = 0, force_output = 0, forced_by_abi = 0, 
  unique_name = 0, used_from_other_partition = 0, in_other_partition = 0, 
  address_taken = 1, order = 777, decl = 0x7ffff6dfc300, 
  next = 0x7ffff6e19668, previous = 0x7ffff6e19a40, 
  next_sharing_asm_name = 0x7ffff6e19b88, previous_sharing_asm_name = 0x0, 
  same_comdat_group = 0x0, ref_list = {references = 0x0, referring = {
      m_vec = 0x1ddfe00}}, alias_target = 0x0, lto_file_data = 0x7ffff7fe1000, 
  aux = 0x0}

that prevails, not the alias

$23 = {type = SYMTAB_FUNCTION, resolution = LDPR_UNKNOWN, definition = 0, 
  alias = 0, weakref = 0, cpp_implicit_alias = 0, analyzed = 0, 
  externally_visible = 0, force_output = 0, forced_by_abi = 0, 
  unique_name = 0, used_from_other_partition = 0, in_other_partition = 0, 
  address_taken = 0, order = 792, decl = 0x7ffff6dfc500, 
  next = 0x7ffff6e19a40, previous = 0x7ffff6e19cd0, 
  next_sharing_asm_name = 0x0, previous_sharing_asm_name = 0x7ffff6e198f8, 
  same_comdat_group = 0x0, ref_list = {references = 0x0, referring = {
      m_vec = 0x0}}, alias_target = 0x0, lto_file_data = 0x7ffff7fe1000, 
  aux = 0x0}

and we replace its cgraph node

*readlinkat/792 (__readlinkat_alias) @0x7ffff6e19b88
  Type: function
  Visibility: external public
  previous sharing asm name: 777
  References: 
  Referring: 
  Read from file: areadlinkat.o
  First run: 0
  Function flags:
  Called by: readlinkat/777 (0.68 per call) 
  Calls: 

by

readlinkat/777 (readlinkat) @0x7ffff6e198f8
  Type: function definition analyzed
  Visibility: resolved_dyn external public
  next sharing asm name: 792
  Address is taken.
  References: 
  Referring: areadlinkat/786 (addr)
  Read from file: areadlinkat.o
  First run: 0
  Function flags:
  Called by: 
  Calls: *readlinkat/792 (0.68 per call) *__readlinkat_chk/791 (0.14 per call)
*__readlinkat_chk/791 (0.18 per call) __builtin_constant_p/789 (0.86 per call)
__builtin_object_size/788 (1.00 per call) 

Note that I think the resolved_dyn should be on the alias, not the inline
body (wouldn't help here I guess, but at least we could choose the one
the linker chose ...).

Index: gcc/lto/lto-symtab.c
===================================================================
--- gcc/lto/lto-symtab.c        (revision 208114)
+++ gcc/lto/lto-symtab.c        (working copy)
@@ -476,7 +476,8 @@ lto_symtab_merge_decls_1 (symtab_node *f
          for (e = first; e; e = e->next_sharing_asm_name)
            if (TREE_CODE (e->decl) == FUNCTION_DECL
                && !DECL_BUILT_IN (e->decl)
-               && lto_symtab_symbol_p (e))
+               && lto_symtab_symbol_p (e)
+               && !e->analyzed)
              {
                prevailing = e;
                break;

fixes it in an awkward way (don't prevail a function with body that wasn't
chosen by the linker).  Not sure if we have to add a fallback then.
(I'd rather chose the symbol with LDPR_RESOLVED_DYN but that's the wrong one
...?).
>From gcc-bugs-return-444775-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Feb 25 13:20:15 2014
Return-Path: <gcc-bugs-return-444775-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12455 invoked by alias); 25 Feb 2014 13:20:14 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12386 invoked by uid 48); 25 Feb 2014 13:20:10 -0000
From: "nheghathivhistha at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/59626] [4.8/4.9 Regression] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining
Date: Tue, 25 Feb 2014 13:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: nheghathivhistha at gmail dot com
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59626-4-z7585xgd9c@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59626-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59626-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg02532.txt.bz2
Content-length: 306

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY626

--- Comment #14 from David Kredba <nheghathivhistha at gmail dot com> ---
For me it is fixed too, tested it by reveision 207938, cp compiles fine with
-flto=4 -fuse-linker-plugin. It crashes later at link time but that is
something completely different.

[Bug lto/59626] [4.8/4.9 Regression] /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
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
           Assignee|rguenth at gcc dot gnu.org         |hubicka at gcc dot gnu.org

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Honza?  Does the patch make sense?  Basically the alias following breaks

int __readlinkat_alias(void) __asm__("readlinkat");
extern inline int readlinkat()
{
    return __readlinkat_alias();
}
int main() {
      return readlinkat();
}

because it replaces __readlinkat_alias () (in main) with readlinkat.

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

[nheghathivhistha at gmail dot com]

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

--- Comment #16 from David Kredba <nheghathivhistha at gmail dot com> ---
Todays Gentoo to tree pushed flac-1.3.0 with gcc-4.9 rev. 208429. The flac
package is still broken in ABI=32 but this should go anyway I think.

/usr/include/bits/stdio2.h: In function
'FLAC__metadata_simple_iterator_get_application_id':
/usr/include/bits/stdio2.h:282:1: error: inlining failed in call to
always_inline 'fread': recursive inlining
 fread (void *__restrict __ptr, size_t __size, size_t __n,
 ^
/usr/include/bits/stdio2.h:295:3: error: called from here
   return __fread_alias (__ptr, __size, __n, __stream);
   ^
make[5]: ***
[/var/tmp/portage/media-libs/flac-1.3.0/temp/ccp3QvqG.ltrans4.ltrans.o] Error 1
make[5]: *** Waiting for unfinished jobs....


Called this way:

libtool: link: x86_64-pc-linux-gnu-gcc -m32 -std=gnu99 -shared  -fPIC -DPIC 
.libs/bitmath.o .libs/bitreader.o .libs/bitwriter.o .libs/cpu.o .libs/crc.o
.libs/fixed.o .libs/float.o .libs/format.o .libs/lpc.o .libs/md5.o
.libs/memory.o .libs/metadata_iterators.o .libs/metadata_object.o
.libs/stream_decoder.o .libs/stream_encoder.o .libs/stream_encoder_framing.o
.libs/window.o .libs/ogg_decoder_aspect.o .libs/ogg_encoder_aspect.o
.libs/ogg_helper.o .libs/ogg_mapping.o  -Wl,--whole-archive
ia32/.libs/libFLAC-asm.a -Wl,--no-whole-archive  -Wl,--as-needed -L/usr/lib
-logg -lm  -m32 -flto=4 -fuse-linker-plugin -O2 -march=native -mtune=native
-mno-3dnow -mno-sse4.2 -mno-avx -flto=4 -fuse-linker-plugin -Wl,-O2 -Wl,-flto
-O2 -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx   -Wl,-soname
-Wl,libFLAC.so.8 -o .libs/libFLAC.so.8.3.0

Binutils are patched by Markus's slim-lto patch.

[Bug lto/59626] [4.8/4.9 Regression] /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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Seems to happen quite often when building packages with LTO (see PR51744 for
another major annoyance there).

[Bug lto/59626] [4.8/4.9 Regression] /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

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> 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.

Note that __readlink_alias was _not_ declared always-inline and thus at least
the call edge (even if eventually re-directing to readlink itself) should
not be considered always-inline.  But we always check the always-inline flag
on the callee decl, even if it was substituted from an alias.  As we throw
away the callgraph edges it's also hard to maintain this edge property there.

[Bug lto/59626] [4.8/4.9 Regression] /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

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
Better patch - simply kill all bodies of extern always_inline functions before
LTO streaming...  (we should be able to do that anyway)

Index: gcc/ipa.c
===================================================================
--- gcc/ipa.c   (revision 208745)
+++ gcc/ipa.c   (working copy)
@@ -1218,6 +1218,29 @@ static unsigned
 free_inline_summary (void)
 {
   inline_free_summary ();
+  /* If we create LTO bytecode then drop bodies of extern always_inline
+     functions now.  */
+  if (flag_lto)
+    {
+      cgraph_node *node;
+      FOR_EACH_DEFINED_FUNCTION (node)
+       if (DECL_EXTERNAL (node->decl)
+           && lookup_attribute ("always_inline",
+                                DECL_ATTRIBUTES (node->decl)) != NULL)
+         {
+           cgraph_release_function_body (node);
+           /* ???  The above doesn't do what I like it to do ;)  */
+           node->analyzed = false;
+           node->definition = false;
+           /* ???  Shouldn't be necessary but the diagnostic code doesn't
+              verify if there is a definition at all.
+              ???  Note attribute lists are possibly shared and
+              remove_attribute doesn't honor that.  */
+           DECL_ATTRIBUTES (node->decl)
+             = remove_attribute ("always_inline",
+                                 DECL_ATTRIBUTES (node->decl));
+         }
+    }
   return 0;
 }

[Bug lto/59626] [4.8/4.9 Regression] /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

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
Testcase:

int __atoi  (const char *) __asm__("atoi");
extern inline __attribute__((always_inline,gnu_inline))
int atoi (const char *x)
{
  return __atoi (x);
}

int bar (int (*)(const char *));

int main()
{
  return bar (atoi);
}

----

int bar (int (*fn)(const char *))
{
  return fn ("0");
}

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

[hubicka at gcc dot gnu.org]

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

--- Comment #21 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Fri Apr  4 18:02:31 2014
New Revision: 209123

URL: http://gcc.gnu.org/viewcvs?rev=209123&root=gcc&view=rev
Log:

    PR ipa/59626
    * lto-cgraph.c (input_overwrite_node): Check that partitioning
    flags are set only during streaming.
    * ipa.c (process_references, walk_polymorphic_call_targets,
    symtab_remove_unreachable_nodes): Drop bodies of always inline
    after early inlining.
    (symtab_remove_unreachable_nodes): Remove always_inline attribute.
    * gcc.dg/lto/pr59626_0.c: New testcase.
    * gcc.dg/lto/pr59626_1.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/lto/pr59626_0.c
    trunk/gcc/testsuite/gcc.dg/lto/pr59626_1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa.c
    trunk/gcc/lto-cgraph.c
    trunk/gcc/testsuite/ChangeLog

[Bug lto/59626] [4.8 Regression] /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
----------------------------------------------------------------------------
      Known to work|                            |4.9.0
            Summary|[4.8/4.9/4.10 Regression]   |[4.8 Regression]
                   |/usr/include/bits/unistd.h: |/usr/include/bits/unistd.h:
                   |173:1: error: inlining      |173:1: error: inlining
                   |failed in call to           |failed in call to
                   |always_inline 'readlinkat': |always_inline 'readlinkat':
                   |recursive inlining          |recursive inlining
      Known to fail|4.9.0                       |

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for 4.9 sofar.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.3                       |4.8.4

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 4.8.3 is being released, adjusting target milestone.

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

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

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

[asolokha at gmx dot com]

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

--- Comment #25 from Arseny Solokha <asolokha at gmx dot com> ---
I observe it when building gcc-6.0.0_alpha20150517 snapshot using gcc 5.1.0
without LTO:

/bin/bash ./libtool --tag=CXX   --mode=compile powerpc-e500v2-linux-gnuspe-c++
-B/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/build/powerpc-e500v2-linux-gnuspe/libstdc++-v3/src/.libs
-B/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/build/powerpc-e500v2-linux-gnuspe/libstdc++-v3/libsupc++/.libs
  -DHAVE_CONFIG_H -I.
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm

-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/linux/powerpc
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/linux
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/powerpc
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/posix
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/generic
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm
 -ftls-model=initial-exec -mhtm -Wall -Werror  -Wc,-pthread -std=gnu++0x
-funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -pipe
-D_GNU_SOURCE -MT util.lo -MD -MP -MF .deps/util.Tpo -c -o util.lo
/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/util.cc
libtool: compile:  powerpc-e500v2-linux-gnuspe-c++
-B/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/build/powerpc-e500v2-linux-gnuspe/libstdc++-v3/src/.libs
-B/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/build/powerpc-e500v2-linux-gnuspe/libstdc++-v3/libsupc++/.libs
-DHAVE_CONFIG_H -I.
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/linux/powerpc
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/linux
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/powerpc
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/posix
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/config/generic
-I/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm
-ftls-model=initial-exec -mhtm -Wall -pthread -Werror -std=gnu++0x
-funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -pipe
-D_GNU_SOURCE -MT util.lo -MD -MP -MF .deps/util.Tpo -c
/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/util.cc
 -fPIC -DPIC -o .libs/util.o
In file included from
/usr/powerpc-e500v2-linux-gnuspe/usr/include/stdio.h:936:0,
                 from
/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/util.cc:27:
/usr/powerpc-e500v2-linux-gnuspe/usr/include/bits/stdio2.h: In function 'void
GTM::gtm_verror(const char*, __va_list_tag*)':
/usr/powerpc-e500v2-linux-gnuspe/usr/include/bits/stdio2.h:124:1: error:
inlining failed in call to always_inline 'int vfprintf(FILE*, const char*,
__va_list_tag*)': function body can be overwritten at link time
 vfprintf (FILE *__restrict __stream,
 ^
/usr/powerpc-e500v2-linux-gnuspe/tmp/portage/sys-devel/gcc-6.0.0_alpha20150517/work/gcc-6-20150517/libitm/util.cc:35:31:
error: called from here
   vfprintf (stderr, fmt, list);
                               ^

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

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 35752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35752&action=edit
backport to 4.8 branch

Note that neither the unreduced multi-file testcase nor the testcase in the
testsuite fail on the 4.8 branch at the moment (but the issue is present
there).

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

[rguenth at gcc dot gnu.org]

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

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Jun 11 13:39:56 2015
New Revision: 224375

URL: https://gcc.gnu.org/viewcvs?rev=224375&root=gcc&view=rev
Log:
2015-06-11  Richard Biener  <rguenther@suse.de>

        Backport from mainline, guarded with in_lto_p
        2015-06-02  Richard Biener  <rguenther@suse.de>

        PR debug/65549
        * dwarf2out.c (lookup_context_die): New function.
        (resolve_addr): Avoid forcing a full DIE for the
        target of a DW_TAG_GNU_call_site during late compilation.
        Instead create a stub DIE without a type if we have a
        context DIE present.

        Backport from mainline
        2014-04-04  Jan Hubicka  <hubicka@ucw.cz>

        PR ipa/59626
        * lto-cgraph.c (input_overwrite_node): Check that partitioning
        flags are set only during streaming.
        * ipa.c (process_references, symtab_remove_unreachable_nodes):
        Drop bodies of always inline after early inlining.
        (symtab_remove_unreachable_nodes): Remove always_inline attribute.

        * gcc.dg/lto/pr59626_0.c: New testcase.
        * gcc.dg/lto/pr59626_1.c: New testcase.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/lto/pr59626_0.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/lto/pr59626_1.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/dwarf2out.c
    branches/gcc-4_8-branch/gcc/ipa.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.