[Bug ipa/64801] New: [5 Regression] kernel build failure due to ICF

[Bug ipa/64801] New: [5 Regression] kernel build failure due to ICF

[trippels at gcc dot gnu.org]

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

            Bug ID: 64801
           Summary: [5 Regression] kernel build failure due to ICF
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org

Created attachment 34574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34574&action=edit
unreduced testcase

Seen on x86_64 with kernel's defconfig.

...
  CC      init/version.o
  LD      init/built-in.o
drivers/built-in.o:psmouse-base.c:function psmouse_extensions: error: undefined
reference to 'fsp_detect'


-fno-ipa-icf "fixes" the issue.

markus@x4 tmp % cat psmouse-base.i
int a;
int
elantech_detect (void)
{
  return -38;
}
inline int
fsp_detect (void)
{
  return -38;
}
void
psmouse_extensions (void)
{
  int (*b)() = fsp_detect;
  a = b ();
}

markus@x4 tmp % gcc -c -O2 psmouse-base.i
markus@x4 tmp % nm psmouse-base.o| grep fsp_detect
                 U fsp_detect

[Bug ipa/64801] [5 Regression] kernel build failure due to ICF

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |5.0

[Bug ipa/64801] [5 Regression] kernel build failure due to ICF

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
You are right, the problem is hidden in cooperation between IPA inliner and
ICF.

If I run the test w/o ICF, inliner sets NULL to the fsp_detect FUNCTION_DECL:

#0  0x000000000074541e in symtab_node::unregister (this=0x7ffff6c47620) at
../../gcc/symtab.c:407
#1  0x000000000074b0ef in cgraph_node::remove (this=0x7ffff6c47620) at
../../gcc/cgraph.c:1741
#2  0x0000000000b891b9 in expand_call_inline (id=0x7fffffffd5c0,
stmt=0x7ffff6d54aa0, bb=<optimized out>)
    at ../../gcc/tree-inline.c:4762
#3  gimple_expand_calls_inline (id=0x7fffffffd5c0, bb=<optimized out>) at
../../gcc/tree-inline.c:4787

so that cgraph_node::get(decl) == NULL here:

    if (symtab->state != LTO_STREAMING) 
   │1784        {
B+>│1785          n = cgraph_node::get (decl);
   │1786          if (!n                      
   │1787              || (!n->clones && !n->clone_of && !n->global.inlined_to
   │1788                  && (symtab->global_info_ready      
   │1789                      && (TREE_ASM_WRITTEN (n->decl) 
   │1790                          || DECL_EXTERNAL (n->decl) 
   │1791                          || !n->analyzed            
   │1792                          || (!flag_wpa && n->in_other_partition)))))  
   │1793            release_body ();                         
   │1794        }                                                         

That's the reason why the body is not removed. On the contrary, with ICF,
aforementioned condition is satisfied and fsp_detect's body is removed.
I think the situation after IPA ICF is correct:

fsp_detect/2 (fsp_detect) @0x7ffff6c47620
  Type: function definition analyzed
  Visibility: external public
  References: 
  Referring: 
  Availability: available
  First run: 0
  Function flags: body
  Called by: elantech_detect/1 (1.00 per call) psmouse_extensions/3 (1.00 per
call) 
  Calls: 
elantech_detect/1 (elantech_detect) @0x7ffff6c47498
  Type: function definition analyzed
  Visibility: externally_visible public
  References: 
  Referring: 
  Availability: available
  First run: 0
  Function flags: body icf_merged
  Called by: 
  Calls: fsp_detect/2 (1.00 per call) 

Can you please help me Honza?
Thanks,
Martin
>From gcc-bugs-return-474916-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 26 15:51:44 2015
Return-Path: <gcc-bugs-return-474916-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28568 invoked by alias); 26 Jan 2015 15:51:31 -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 28292 invoked by uid 48); 26 Jan 2015 15:51:14 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/64776] [5 Regression] FAIL: gcc.dg/ipa/pr64307.c (internal compiler error) on x86_64-apple-darwin14
Date: Mon, 26 Jan 2015 15:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64776-4-MRPoz2Ff5c@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64776-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64776-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: 2015-01/txt/msg02910.txt.bz2
Content-length: 245

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd776

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Sorry for the duplicate comments 5 and 6. Bugzilla is very slow and I got a
confusing message about gateway timed out.

[Bug ipa/64801] [5 Regression] kernel build failure due to ICF

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-01-27
                 CC|                            |hubicka at gcc dot gnu.org
           Assignee|marxin at gcc dot gnu.org          |hubicka at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I will take a look.

[Bug ipa/64801] [5 Regression] kernel build failure due to ICF

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, the testcase is buggy: fsp_detect should be static inline.  GCC is valid to
not inline it and not produce offline copy because that should be produced by
other unit.

What happens is that icf merge elantech_detect and fsp_detect:

Parsed function:fsp_detect                                                      
fsp_detect ()                                                                   
{                                                                               
  <bb 2>:                                                                       
  return -38;                                                                   

}                                                                               


Parsed function:elantech_detect                                                 
elantech_detect ()                                                              
{                                                                               
  <bb 2>:                                                                       
  return -38;                                                                   

}                                                                               

and turns elantech_detect into a thunk calling fsp_detect (not much of point in
doing that but all right).  Eventually we fail inline:

  not inlinable: elantech_detect/1 -> fsp_detect/2, mismatched arguments        
   Estimating body: fsp_detect/2                                                
   Known to be false: not inlined                                               
   size:0 time:0                                                                

So the question is why we consider the call as having mismatch?

[Bug ipa/64801] [5 Regression] kernel build failure due to ICF

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, we do not inline it because creae_wrapper decides so:
Index: cgraphunit.c
===================================================================
--- cgraphunit.c        (revision 220229)
+++ cgraphunit.c        (working copy)
@@ -2427,7 +2427,6 @@ cgraph_node::create_wrapper (cgraph_node
     }

   expand_thunk (false, true);
-  e->call_stmt_cannot_inline_p = true;

   /* Inline summary set-up.  */
   analyze ();

Martin, perhaps this is leftover of some debugging? We ought to give inliner
freedom to re-duplicate the unified function body when it seems profitable
(like here)

[Bug ipa/64801] [5 Regression] kernel build failure due to ICF

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Introduced already in https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02574.html

We may need to inform inliner that calls inside thunk are cheap (and count them
with code/size cost 1) for better size results.

[Bug ipa/64801] [5 Regression] kernel build failure due to ICF

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Thu Jan 29 07:43:14 2015
New Revision: 220230

URL: https://gcc.gnu.org/viewcvs?rev=220230&root=gcc&view=rev
Log:
    PR ipa/64801
    * gcc.dg/tree-ssa/pr64801.c: New testcase.
    * cgraphunit.c (init_lowered_empty_function): Add CoUNT parameter;
    make sane BB profile.
    (cgraph_node::expand_thunk): Make sane BB profile.
    (cgraph_node::create_wrapper): Do not set call_stmt_cannot_inline_p.
    * cgraph.h (init_lowered_empty_function): Update prototype.
    * config/i386/i386.c (make_resolver_func): Update call.
    * predict.c (gate): Disable branch prediction pass if
    profile is already there.

Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr64801.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraph.h
    trunk/gcc/cgraphunit.c
    trunk/gcc/config/i386/i386.c
    trunk/gcc/predict.c
    trunk/gcc/testsuite/ChangeLog

[Bug ipa/64801] [5 Regression] kernel build failure due to ICF

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Fixed.