[Bug middle-end/63766] New: [5 Regression] ICE: in gimple_predict_edge, at predict.c:578

[Bug middle-end/63766] New: [5 Regression] ICE: in gimple_predict_edge, at predict.c:578

[trippels at gcc dot gnu.org]

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

            Bug ID: 63766
           Summary: [5 Regression] ICE: in gimple_predict_edge, at
                    predict.c:578
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org

trippels@gcc2-power8 AST % cat ASTDumper.ii
class A
{
public:
  void
  getValueType ()
  {
  }
  void getTypeClass ();
};
template <typename ImplClass> class B
{
public:
  void
  Visit (A *p1)
  {
    p1->getTypeClass ();
    static_cast<ImplClass *> (0)->VisitAtomicType (0);
  }
};
class C : B<C>
{
  template <typename Fn>
  void
  dumpChild (Fn p1)
  {
    p1 ();
  }

public:
  void dumpTypeAsChild (int);
  void
  VisitAtomicType (A *p1)
  {
    p1->getValueType ();
    dumpTypeAsChild (0);
  }
};
void
C::dumpTypeAsChild (int)
{
  dumpChild ([=]
             {
               Visit (0);
             });
}

trippels@gcc2-power8 AST % g++ -std=c++11 -O2 -c ASTDumper.ii
ASTDumper.ii: In function ‘C::dumpTypeAsChild(int)::<lambda()>’:
ASTDumper.ii:45:1: internal compiler error: in gimple_predict_edge, at
predict.c:578
 }
 ^
0x108a4513 gimple_predict_edge(edge_def*, br_predictor, int)
        ../../gcc/gcc/predict.c:578
0x104ea027 predict_edge(edge_def*, br_predictor, int)
        ../../gcc/gcc/cfghooks.c:737
0x108a37ab predict_edge_def
        ../../gcc/gcc/predict.c:664
0x108a37ab predict_loops
        ../../gcc/gcc/predict.c:1581
0x108a37ab tree_estimate_probability()
        ../../gcc/gcc/predict.c:2344
0x108a41e3 execute
        ../../gcc/gcc/predict.c:3056
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-465905-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 06 20:00:39 2014
Return-Path: <gcc-bugs-return-465905-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 322 invoked by alias); 6 Nov 2014 20:00:39 -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 32767 invoked by uid 48); 6 Nov 2014 20:00:36 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/63766] [5 Regression] ICE: in gimple_predict_edge, at predict.c:578
Date: Thu, 06 Nov 2014 20:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels 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: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc target_milestone
Message-ID: <bug-63766-4-7GuWtzFcOO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63766-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63766-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-11/txt/msg00377.txt.bz2
Content-length: 473

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ienkovich at gcc dot gnu.org
   Target Milestone|---                         |5.0

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Started with r217125.

[Bug middle-end/63766] [5 Regression] ICE: in gimple_predict_edge, at predict.c:578

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug middle-end/63766] [5 Regression] ICE: in gimple_predict_edge, at predict.c:578

[enkovich.gnu at gmail dot com]

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

--- Comment #2 from Ilya Enkovich <enkovich.gnu at gmail dot com> ---
Problem caused by the fact that now all function come to local optimizations in
SSA form.  It affects inline parameters computation and therefore inlining
order.

During early SRA we call convert_callers_for_node which recomputes inline
parameters for functions in SSA form.  Previously it was computed only for
function already processed by all early local passes.  Now all functions are in
SSA form and it means we may recompute inline parameters for function not yet
processed by local optimizations.

In this test we have function marked as inlinable which is not yet processed in
do_per_function_toporder called for local_optimization_passes.  It allows this
function to be inlined and removed before it is actually processed (and still
sit in order vector).  Another cgraph_node created by SRA is allocated at the
same slot as removed one and thus the same function is processed twice, which
causes ICE in profiling pass.

Solution here would be to either use another condition for inline_parameters
recomputation or to handle nodes removal in do_per_function_toporder by
registering proper node removal hook.  Suppose the latter is better because
allows more early inlining.

Here is a possible fix (works for reproducer, not fully tested):

diff --git a/gcc/passes.c b/gcc/passes.c
index 5e91a79..4799efa 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -1609,6 +1609,19 @@ do_per_function (void (*callback) (function *, void
*data), void *data)
 static int nnodes;
 static GTY ((length ("nnodes"))) cgraph_node **order;

+static void
+remove_cgraph_node_from_order (cgraph_node *node, void *)
+{
+  int i;
+
+  for (i = 0; i < nnodes; i++)
+    if (order[i] == node)
+      {
+       order[i] = NULL;
+       return;
+      }
+}
+
 /* If we are in IPA mode (i.e., current_function_decl is NULL), call
    function CALLBACK for every function in the call graph.  Otherwise,
    call CALLBACK on the current function.
@@ -1622,13 +1635,20 @@ do_per_function_toporder (void (*callback) (function *,
void *data), void *data)
     callback (cfun, data);
   else
     {
+      cgraph_node_hook_list *hook;
       gcc_assert (!order);
       order = ggc_vec_alloc<cgraph_node *> (symtab->cgraph_count);
       nnodes = ipa_reverse_postorder (order);
       for (i = nnodes - 1; i >= 0; i--)
         order[i]->process = 1;
+      hook = symtab->add_cgraph_removal_hook (remove_cgraph_node_from_order,
+                                             NULL);
       for (i = nnodes - 1; i >= 0; i--)
        {
+         /* Function could be inlined and removed as unreachable.  */
+         if (!order[i])
+           continue;
+
          struct cgraph_node *node = order[i];

          /* Allow possibly removed nodes to be garbage collected.  */
@@ -1637,6 +1657,7 @@ do_per_function_toporder (void (*callback) (function *,
void *data), void *data)
          if (node->has_gimple_body_p ())
            callback (DECL_STRUCT_FUNCTION (node->decl), data);
        }
+      symtab->remove_cgraph_removal_hook (hook);
     }
   ggc_free (order);
   order = NULL;

[Bug middle-end/63766] [5 Regression] ICE: in gimple_predict_edge, at predict.c:578

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Ilya Enkovich from comment #2)
> Problem caused by the fact that now all function come to local optimizations
> in SSA form.  It affects inline parameters computation and therefore
> inlining order.
> 
> During early SRA we call convert_callers_for_node which recomputes inline
> parameters for functions in SSA form.  Previously it was computed only for
> function already processed by all early local passes.  Now all functions are
> in SSA form and it means we may recompute inline parameters for function not
> yet processed by local optimizations.
> 
> In this test we have function marked as inlinable which is not yet processed
> in do_per_function_toporder called for local_optimization_passes.  It allows
> this function to be inlined and removed before it is actually processed (and
> still sit in order vector).  Another cgraph_node created by SRA is allocated
> at the same slot as removed one and thus the same function is processed
> twice, which causes ICE in profiling pass.
> 
> Solution here would be to either use another condition for inline_parameters
> recomputation or to handle nodes removal in do_per_function_toporder by
> registering proper node removal hook.  Suppose the latter is better because
> allows more early inlining.
> 
> Here is a possible fix (works for reproducer, not fully tested):
> 
> diff --git a/gcc/passes.c b/gcc/passes.c
> index 5e91a79..4799efa 100644
> --- a/gcc/passes.c
> +++ b/gcc/passes.c
> @@ -1609,6 +1609,19 @@ do_per_function (void (*callback) (function *, void
> *data), void *data)
>  static int nnodes;
>  static GTY ((length ("nnodes"))) cgraph_node **order;
> 
> +static void
> +remove_cgraph_node_from_order (cgraph_node *node, void *)
> +{
> +  int i;
> +
> +  for (i = 0; i < nnodes; i++)
> +    if (order[i] == node)
> +      {
> +       order[i] = NULL;
> +       return;
> +      }
> +}

That's quadratic in the number of nodes and thus a no-go.  Why not delay
removing of unreachable nodes instead?  If you go with the above then
you need to change that data-structure used.

>  /* If we are in IPA mode (i.e., current_function_decl is NULL), call
>     function CALLBACK for every function in the call graph.  Otherwise,
>     call CALLBACK on the current function.
> @@ -1622,13 +1635,20 @@ do_per_function_toporder (void (*callback) (function
> *, void *data), void *data)
>      callback (cfun, data);
>    else
>      {
> +      cgraph_node_hook_list *hook;
>        gcc_assert (!order);
>        order = ggc_vec_alloc<cgraph_node *> (symtab->cgraph_count);
>        nnodes = ipa_reverse_postorder (order);
>        for (i = nnodes - 1; i >= 0; i--)
>          order[i]->process = 1;
> +      hook = symtab->add_cgraph_removal_hook (remove_cgraph_node_from_order,
> +                                             NULL);
>        for (i = nnodes - 1; i >= 0; i--)
>         {
> +         /* Function could be inlined and removed as unreachable.  */
> +         if (!order[i])
> +           continue;
> +
>           struct cgraph_node *node = order[i];
> 
>           /* Allow possibly removed nodes to be garbage collected.  */
> @@ -1637,6 +1657,7 @@ do_per_function_toporder (void (*callback) (function
> *, void *data), void *data)
>           if (node->has_gimple_body_p ())
>             callback (DECL_STRUCT_FUNCTION (node->decl), data);
>         }
> +      symtab->remove_cgraph_removal_hook (hook);
>      }
>    ggc_free (order);
>    order = NULL;

[Bug middle-end/63766] [5 Regression] ICE: in gimple_predict_edge, at predict.c:578

[enkovich.gnu at gmail dot com]

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

--- Comment #5 from Ilya Enkovich <enkovich.gnu at gmail dot com> ---
I forgot to mention PR in a ChangeLog.  Patch is in trunk:
https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00707.html

[Bug middle-end/63766] [5 Regression] ICE: in gimple_predict_edge, at predict.c:578

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #6 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Fixed. Thanks, Ilya.