From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30980 invoked by alias); 25 Feb 2014 12:44:27 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 30931 invoked by uid 48); 25 Feb 2014 12:44:23 -0000 From: "rguenth at gcc dot 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 12:44: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: rguenth at gcc dot gnu.org 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: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg02531.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59626 --- Comment #13 from Richard Biener --- (In reply to Markus Trippelsdorf from comment #12) > Created attachment 32210 [details] > Unreduced testcase >=20 > Here's the unreduced testcase: >=20 > markus@x4 coreutils % gcc -std=3Dgnu99 -flto -O2 cp.i copy.i areadlinkat.i > careadlinkat.i linkat.i > /usr/include/bits/unistd.h: In function =E2=80=98careadlinkat.constprop= =E2=80=99: > /usr/include/bits/unistd.h:173:42: error: inlining failed in call to > always_inline =E2=80=98readlinkat=E2=80=99: 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/bi= n/ > 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 inlin= ed) 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) =3D=3D FUNCTION_DECL) { for (e =3D first; e; e =3D e->next_sharing_asm_name) if (TREE_CODE (e->decl) =3D=3D FUNCTION_DECL && !DECL_BUILT_IN (e->decl) && lto_symtab_symbol_p (e)) { prevailing =3D e; break; } Now it is readlinkat $22 =3D {type =3D SYMTAB_FUNCTION, resolution =3D LDPR_RESOLVED_DYN, defini= tion =3D 1,=20 alias =3D 0, weakref =3D 0, cpp_implicit_alias =3D 0, analyzed =3D 1,=20 externally_visible =3D 0, force_output =3D 0, forced_by_abi =3D 0,=20 unique_name =3D 0, used_from_other_partition =3D 0, in_other_partition = =3D 0,=20 address_taken =3D 1, order =3D 777, decl =3D 0x7ffff6dfc300,=20 next =3D 0x7ffff6e19668, previous =3D 0x7ffff6e19a40,=20 next_sharing_asm_name =3D 0x7ffff6e19b88, previous_sharing_asm_name =3D 0= x0,=20 same_comdat_group =3D 0x0, ref_list =3D {references =3D 0x0, referring = =3D { m_vec =3D 0x1ddfe00}}, alias_target =3D 0x0, lto_file_data =3D 0x7fff= f7fe1000,=20 aux =3D 0x0} that prevails, not the alias $23 =3D {type =3D SYMTAB_FUNCTION, resolution =3D LDPR_UNKNOWN, definition = =3D 0,=20 alias =3D 0, weakref =3D 0, cpp_implicit_alias =3D 0, analyzed =3D 0,=20 externally_visible =3D 0, force_output =3D 0, forced_by_abi =3D 0,=20 unique_name =3D 0, used_from_other_partition =3D 0, in_other_partition = =3D 0,=20 address_taken =3D 0, order =3D 792, decl =3D 0x7ffff6dfc500,=20 next =3D 0x7ffff6e19a40, previous =3D 0x7ffff6e19cd0,=20 next_sharing_asm_name =3D 0x0, previous_sharing_asm_name =3D 0x7ffff6e198= f8,=20 same_comdat_group =3D 0x0, ref_list =3D {references =3D 0x0, referring = =3D { m_vec =3D 0x0}}, alias_target =3D 0x0, lto_file_data =3D 0x7ffff7fe10= 00,=20 aux =3D 0x0} and we replace its cgraph node *readlinkat/792 (__readlinkat_alias) @0x7ffff6e19b88 Type: function Visibility: external public previous sharing asm name: 777 References:=20 Referring:=20 Read from file: areadlinkat.o First run: 0 Function flags: Called by: readlinkat/777 (0.68 per call)=20 Calls:=20 by readlinkat/777 (readlinkat) @0x7ffff6e198f8 Type: function definition analyzed Visibility: resolved_dyn external public next sharing asm name: 792 Address is taken. References:=20 Referring: areadlinkat/786 (addr) Read from file: areadlinkat.o First run: 0 Function flags: Called by:=20 Calls: *readlinkat/792 (0.68 per call) *__readlinkat_chk/791 (0.14 per ca= ll) *__readlinkat_chk/791 (0.18 per call) __builtin_constant_p/789 (0.86 per ca= ll) __builtin_object_size/788 (1.00 per call)=20 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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 =3D first; e; e =3D e->next_sharing_asm_name) if (TREE_CODE (e->decl) =3D=3D FUNCTION_DECL && !DECL_BUILT_IN (e->decl) - && lto_symtab_symbol_p (e)) + && lto_symtab_symbol_p (e) + && !e->analyzed) { prevailing =3D 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=59626 --- Comment #14 from David Kredba --- 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.