[Bug lto/65130] New: ICE with LTO on valid code on x86_64-linux-gnu

[Bug lto/65130] New: ICE with LTO on valid code on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

            Bug ID: 65130
           Summary: ICE with LTO on valid code on x86_64-linux-gnu
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk with
LTO on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 4.9.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150219 (experimental) [trunk revision 220822] (GCC) 
$ 
$ gcc-4.9 -flto -O1 -c foo.c
$ gcc-4.9 -flto -O2 -c main.c
$ gcc-4.9 -flto -O1 foo.o main.o
$ ./a.out
$ 
$ gcc-trunk -flto -O1 -c foo.c
$ gcc-trunk -flto -O2 -c main.c
$ gcc-trunk -flto -O1 foo.o main.o
gcc-trunk: internal compiler error: Segmentation fault (program lto1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: gcc-trunk returned 4 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ 
$ cat foo.c
extern void fn3 (void); 

void fn2(void) 
{ 
  fn3(); 
}

void fn1(void) 
{ 
  fn2(); 
}

void fn4(void) 
{ 
  fn2(); 
}
$ cat main.c
extern void fn1(void);
extern void fn4 (void); 

int a; 

void fn3(void) 
{
  for (; a;)
    fn4();
}

int main() {
  fn1();
  return 0;
}
$

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-20
                 CC|                            |hubicka at gcc dot gnu.org
      Known to work|                            |4.9.2
   Target Milestone|---                         |5.0
            Summary|ICE with LTO on valid code  |[5 Regression] ICE with LTO
                   |on x86_64-linux-gnu         |on valid code on
                   |                            |x86_64-linux-gnu
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed - segfaults during WPA stage.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000a4e987 in inline_edge_summary (edge=0x7ffff68d5270)
    at /space/rguenther/src/svn/trunk/gcc/ipa-inline.h:275
275       return &inline_edge_summary_vec[edge->uid];
Missing separate debuginfos, use: zypper install
libgmp10-debuginfo-6.0.0-71.1.x86_64 libisl13-debuginfo-0.14-25.2.x86_64
libmpc3-debuginfo-1.0.2-38.2.x86_64
(gdb) bt
#0  0x0000000000a4e987 in inline_edge_summary (edge=0x7ffff68d5270)
    at /space/rguenther/src/svn/trunk/gcc/ipa-inline.h:275
#1  0x0000000000a57c4d in estimate_calls_size_and_time (
    node=<cgraph_node* 0x7ffff68dbab8 "fn4">, size=0x7ffff6ac726c, 
    min_size=0x7ffff6ac7250, time=0x7ffff6ac7268, hints=0x0, 
    possible_truths=4294967294, known_vals=..., known_contexts=..., 
    known_aggs=...)
    at /space/rguenther/src/svn/trunk/gcc/ipa-inline-analysis.c:3115
...
#1234 0x0000000000a57d62 in estimate_calls_size_and_time (
    node=<cgraph_node* 0x7ffff68dbab8 "fn4">, size=0x7ffff6ac726c, 
    min_size=0x7ffff6ac7250, time=0x7ffff6ac7268, hints=0x0, 
    possible_truths=4294967294, known_vals=..., known_contexts=..., 
    known_aggs=...)
    at /space/rguenther/src/svn/trunk/gcc/ipa-inline-analysis.c:3141
(and more)

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |aldyh at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I'll take a stab at analyzing.  If anyone else is analyzing, please say so, to
avoid duplicating effort.

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|aldyh at gcc dot gnu.org           |unassigned at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Returning to queue, as Kai Tietz is looking at this with Honza.

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[ktietz at gcc dot gnu.org]

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

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

--- Comment #4 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Created attachment 34876
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34876&action=edit
Suggested patch avoiding endless-recursing by hash_set for visted edges

The patch solves the reported issue for me on x86_64-unknown-linux-gnu.
It avoids that we recurse within functions we already visited.
While working on this I noticed that code uses pretty much stack due passing
vecs' as copy on stack.  This makes especially on targets with fixed amount of
stack seriously troubles.  But well, this is nothing to address by this patch

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[ktietz at gcc dot gnu.org]

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ktietz at gcc dot gnu.org

--- Comment #5 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Mine, for now

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
FWIW, problem started with:

commit 6a0440477bc2a41ade7254552829f320755d0f0f
Author: hubicka <hubicka@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Sat Feb 14 23:46:25 2015 +0000

        * ipa-inline-analysis.c (growth_data): Add uninlinable field.
        (do_estimate_growth_1): Record if any uninlinable edge was seen.
        (estimate_growth): Handle uninlinable edges correctly.
        (check_callers): New.
        (growth_likely_positive): Handle aliases correctly.

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Does this still reproduce? It works with my tree (that has one ipa-icf fix I am
about to commit today). As disucssed earlier, cycles in
estimate_calls_size_and_time should not happen, because the function walks
inline tree that can not have loops. So the bug is earlier. I would suspect
that ipa-icf may make mess of aliases causing this to happen (that should be
caught by the verifier but perhaps it isn't)

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[aldyh at gcc dot gnu.org]

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

--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Cannot reproduce.

Fixed on mainline by:

commit b9cb01c10d90420929551763dae489c1ef53af93
Author: hubicka <hubicka@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Sun Mar 1 01:08:47 2015 +0000

        * ipa-inline.c (can_inline_edge_p): Match opt_for_fn on inline
        target; also match flag_ipa_devirt.


    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@221084
138bc75d-0d04-0410-961f-82ee72b054a4

Can we close this PR, or is the above patch just papering over the issue?

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Aha, almost definitely papering over.  I will check tomorrow, thanks!

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The bug is:

fn3/5 (fn3) @0x7ffff6ae5dc8
  Type: function definition analyzed
  Visibility: prevailing_def_ironly
  previous sharing asm name: 11
  References: a/4 (read)
  Referring: 
  Read from file: b.o
  Availability: local
  First run: 0
  Function flags: local
  Called by: fn2/10 (inlined) (10.11 per call) fn2/0 (1.00 per call) 
  Calls: fn4/2 (inlined) (10.11 per call) 

fn3 is not inlined clone but it is still called by fn2 and inlined into it.
This is why we end up producing a cycle in the inline tree.

This seems to be introduced by code inlining functions called once. I suppose
there is a problem with nodes being removed and walked at the same time. Will
check more tomorrow.

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[hubicka at ucw dot cz]

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

--- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> ---
Hi,
the bug is caused by code inlining functions called once.  Here is a dead
self recursive function that is called once (from itself) and the inliner
manages
to not punt on the rcurisve call and produce cycle.

The following patch ought to fix it.
Index: ipa-inline-analysis.c
===================================================================
--- ipa-inline-analysis.c    (revision 221096)
+++ ipa-inline-analysis.c    (working copy)
@@ -1291,7 +1291,8 @@ inline_summary_t::duplicate (cgraph_node
       set_hint_predicate (&info->array_index, p);
     }
     }
-  inline_update_overall_summary (dst);
+  if (!dst->global.inlined_to)
+    inline_update_overall_summary (dst);
 }


@@ -3924,10 +3925,11 @@ do_estimate_growth_1 (struct cgraph_node
           continue;
     }

-      if (e->caller == d->node
-      || (e->caller->global.inlined_to
-          && e->caller->global.inlined_to == d->node))
-    d->self_recursive = true;
+      if (e->recursive_p ())
+    {
+      d->self_recursive = true;
+      continue;
+    }
       d->growth += estimate_edge_growth (e);
     }
   return false;
Index: ipa-inline.c
===================================================================
--- ipa-inline.c    (revision 221096)
+++ ipa-inline.c    (working copy)
@@ -952,6 +952,8 @@ check_callers (struct cgraph_node *node,
      return true;
        if (!can_inline_edge_p (e, true))
          return true;
+       if (e->recursive_p ())
+     return true;
        if (!(*(bool *)has_hot_call) && e->maybe_hot_p ())
      *(bool *)has_hot_call = true;
      }
@@ -2094,6 +2096,15 @@ inline_to_all_callers (struct cgraph_nod
     {
       struct cgraph_node *caller = node->callers->caller;

+      if (!can_inline_edge_p (node->callers, true)
+      || node->callers->recursive_p ())
+    {
+      if (dump_file)
+        fprintf (dump_file, "Uninlinable call found; giving up.\n");
+      *num_calls = 0;
+      return false;
+    }
+
       if (dump_file)
     {
       fprintf (dump_file,

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[ktietz at gcc dot gnu.org]

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

--- Comment #12 from Kai Tietz <ktietz at gcc dot gnu.org> ---
I confirm that bug is fixed with that patch.  Only for the case that trying to
link with objects created with prior revision will still fail.  Later might be
acceptable.

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Mon Mar  2 20:31:21 2015
New Revision: 221124

URL: https://gcc.gnu.org/viewcvs?rev=221124&root=gcc&view=rev
Log:

    PR ipa/65130
    * ipa-inline.c (check_callers): Looks for recursion.
    (inline_to_all_callers): Give up on uninlinable or recursive edges.
    * ipa-inline-analysis.c (inline_summary_t::duplicate): Do not update
    summary of inline clones.
    (do_estimate_growth_1): Fix recursion check.

    * gcc.dg/lto/pr65130_0.c: New testcase.
    * gcc.dg/lto/pr65130_1.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/lto/pr65130_0.c
    trunk/gcc/testsuite/gcc.dg/lto/pr65130_1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-inline-analysis.c
    trunk/gcc/ipa-inline.c
    trunk/gcc/testsuite/ChangeLog

[Bug lto/65130] [5 Regression] ICE with LTO on valid code on x86_64-linux-gnu

[hubicka at gcc dot gnu.org]

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

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

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

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