[Bug tree-optimization/56265] New: [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[Bug tree-optimization/56265] New: [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jakub at gcc dot gnu.org]

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

             Bug #: 56265
           Summary: [4.8 Regression] ICE in ipa_make_edge_direct_to_target
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: hubicka@gcc.gnu.org


int baz ();
struct A
{
  virtual int fn2 () = 0;
  virtual int *fn3 ();
  double *fn4 ();
  int fn5 (int);
  template <class T>
  void fn1 (A &, T) { fn3 (); fn4 (); fn2 (); }
};
struct B : A
{
  int fn2 () { return 6; }
  void fn3 (int, double);
  B (bool = true);
  B (int, int);
};
template <typename T>
void
foo (B &x, A &y, A &z)
{
  y.fn2 ();
  z.fn2 ();
  int i = baz ();
  int j = (y.fn3 ())[i];
  x.fn3 (j, (y.fn4 ())[i] + (z.fn4 ())[z.fn5 (j)]);
}
inline B
operator+ (A &y, A &z)
{
  B x;
  foo<int> (x, y, z);
  return x;
}
void
bar ()
{
  B a, b, c (4, 0), d;
  a.fn1 (b, .6);
  baz ();
  c + d;
}

ICEs at -O2, starting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195066

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-02-09
   Target Milestone|---                         |4.8.0
     Ever Confirmed|0                           |1

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[ppluzhnikov at google dot com]

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

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at google dot
                   |                            |com

--- Comment #1 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2013-02-10 18:45:31 UTC ---
*** Bug 56262 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-11 16:20:24 UTC ---
--- gcc/ipa-inline.c.jj    2013-01-11 09:02:48.000000000 +0100
+++ gcc/ipa-inline.c    2013-02-11 17:16:04.951958702 +0100
@@ -1792,7 +1792,7 @@ ipa_inline (void)
     }

   inline_small_functions ();
-  symtab_remove_unreachable_nodes (false, dump_file);
+  symtab_remove_unreachable_nodes (true, dump_file);
   free (order);

   /* Inline functions with a property that after inlining into all callers the
@@ -1876,6 +1876,9 @@ ipa_inline (void)

   if (dump_file)
     dump_inline_summaries (dump_file);
+
+  symtab_remove_unreachable_nodes (false, dump_file);
+
   /* In WPA we use inline summaries for partitioning process.  */
   if (!flag_wpa)
     inline_free_summary ();

fixes this.

The gcc-patches post said:
"This is bug.  The cleanup is supposed to happen just before inlining functions
called once.  The patch also adds the cleanup to same place into
do_whole_program_analysis and updates cgraphclones.c so we do not ice when
removing offline copy of the function after inlining."

but clearly that is too early, as the testcase shows.

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[ppluzhnikov at google dot com]

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

--- Comment #3 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2013-02-12 00:48:01 UTC ---
Thanks for the fix.

We've confirmed that this fix also fixes the crash in "irreducible" test case
from PR56262.

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka <hubicka at ucw dot cz> 2013-02-12 17:25:31 UTC ---
Hi,
this patch should make ipa_make_edge_direct_to_target to behave properly when
new symbol
needs to be inserted into the symbol table.   We already have
canonicalize_constructor_val
to do the right thing (i.e. check we can refer to the symbol), but we need to
update
symbol table in that case, too.
I also took the chance to add more detailed debug output.

I will give this patch more testing on Mozilla/Qt tomorrow and produce some
statistic.
here is some chance of provoking some latent bug in
canonicalize_constructor_val
since we get bit more devirtualizations tham previously.  It however ought not
be
much of issue since all of them can be produced on old tree by adding another
function allowing local devirtualization and inserting the symbol into symtab.

Honza

Index: ipa-prop.c
===================================================================
--- ipa-prop.c    (revision 195956)
+++ ipa-prop.c    (working copy)
@@ -2100,10 +2100,65 @@ ipa_make_edge_direct_to_target (struct c
   if (TREE_CODE (target) == ADDR_EXPR)
     target = TREE_OPERAND (target, 0);
   if (TREE_CODE (target) != FUNCTION_DECL)
-    return NULL;
+    {
+      target = canonicalize_constructor_val (target, NULL);
+      if (!target || TREE_CODE (target) != FUNCTION_DECL)
+    {
+      if (dump_file)
+        fprintf (dump_file, "ipa-prop: Discovered direct call to non-function"
+                " in (%s/%i).\n",
+             cgraph_node_name (ie->caller), ie->caller->uid);
+      return NULL;
+    }
+    }
   callee = cgraph_get_node (target);
-  if (!callee)
-    return NULL;
+
+  /* Because may-edges are not explicitely represented and vtable may be
external,
+     we may create the first reference to the object in the unit.  */
+  if (!callee || callee->global.inlined_to)
+    {
+      struct cgraph_node *first_clone = callee;
+
+      /* We are better to ensure we can refer to it.
+     In the case of static functions we are out of luck, since we already    
+     removed its body.  In the case of public functions we may or may
+     not introduce the reference.  */
+      if (!canonicalize_constructor_val (target, NULL)
+      || !TREE_PUBLIC (target))
+    {
+      if (dump_file)
+        fprintf (dump_file, "ipa-prop: Discovered call to a known target "
+             "(%s/%i -> %s/%i) but can not refer to it. Giving up.\n",
+             xstrdup (cgraph_node_name (ie->caller)), ie->caller->uid,
+             xstrdup (cgraph_node_name (ie->callee)), ie->callee->uid);
+      return NULL;
+    }
+
+      /* Create symbol table node.  Even if inline clone exists, we can not
take
+     it as a target of non-inlined call.  */
+      callee = cgraph_create_node (target);
+
+      /* OK, we previously inlined the function, then removed the offline copy
and
+     now we want it back for external call.  This can happen when
devirtualizing
+     while inlining function called once that happens after extern inlined and
+     virtuals are already removed.  In this case introduce the external node
+     and make it available for call.  */
+      if (first_clone)
+    {
+      first_clone->clone_of = callee;
+      callee->clones = first_clone;
+      symtab_prevail_in_asm_name_hash ((symtab_node)callee);
+      symtab_insert_node_to_hashtable ((symtab_node)callee);
+      if (dump_file)
+        fprintf (dump_file, "ipa-prop: Introduced new external node "
+             "(%s/%i) and turned into root of the clone tree.\n",
+             xstrdup (cgraph_node_name (callee)), callee->uid);
+    }
+      else if (dump_file)
+    fprintf (dump_file, "ipa-prop: Introduced new external node "
+         "(%s/%i).\n",
+         xstrdup (cgraph_node_name (callee)), callee->uid);
+    }
   ipa_check_create_node_params ();

   /* We can not make edges to inline clones.  It is bug that someone removed

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[aldyh at gcc dot gnu.org]

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

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

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

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2013-02-13 17:16:12 UTC ---
*** Bug 56290 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-18 14:27:29 UTC ---
Honza, any progress on this?

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> 2013-02-19 06:46:20 UTC ---
> Honza, any progress on this?
Oops, forgot to check the Firefox results. I am currently on a way, will do it
once arriving.

Honza

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> 2013-02-19 21:09:54 UTC ---
> 
Hi,
the patch seems to work well for Mozilla.  There are two issues I noticed while
testing it
 1) we now enable-checking ICE on cgraph_mark_address_taken when compiling
Mozilla with FDO.
    It is independent problem I was looking into for good part of day today. In
fact we need
    to do similar excercise when this happen, but I wil handle this
incrementally.
    It is WHOPR only bug.
 2) The warning about calling a non-function surprisingly triggers few times
during Mozilla.
    The values are constants:
 <integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
 <integer_cst 0x7f204342bb00 type <pointer_type 0x7f1fee1d9a80> constant 33>
 <integer_cst 0x7f204342ba40 type <pointer_type 0x7f1fee1d9a80> constant 81>
 <integer_cst 0x7f1ffcb795a0 type <pointer_type 0x7f1fea0a4a80> constant 113>
 <integer_cst 0x7f1ffcb795a0 type <pointer_type 0x7f1fea0a4a80> constant 113>
 <integer_cst 0x7f1ffe6bca00 type <pointer_type 0x7f1fea0a4a80> constant 121>
 <integer_cst 0x7f1ffe6bca00 type <pointer_type 0x7f1fea0a4a80> constant 121>
 <integer_cst 0x7f204342baa0 type <pointer_type 0x7f1fee1d9930> constant 49>
 <integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
 <integer_cst 0x7f1fdc69e8e0 type <pointer_type 0x7f1fd938ad20> constant 0>
 <integer_cst 0x7f1fdc69e8e0 type <pointer_type 0x7f1fd938ad20> constant 0>
 <integer_cst 0x7f202b5d5160 type <pointer_type 0x7f1ff919fc78 JSErrorCallback>
constant 0>
 <integer_cst 0x7f1ffe6bca00 type <pointer_type 0x7f1fea0a4a80> constant 121>
 <integer_cst 0x7f1ffe6bca00 type <pointer_type 0x7f1fea0a4a80> constant 121>
 <integer_cst 0x7f1ffcb795a0 type <pointer_type 0x7f1fea0a4a80> constant 113>
 <integer_cst 0x7f1ffcb795a0 type <pointer_type 0x7f1fea0a4a80> constant 113>
 <integer_cst 0x7f202b5d5160 type <pointer_type 0x7f1ff919fc78 JSErrorCallback>
constant 0>
 <integer_cst 0x7f204342b940 type <pointer_type 0x7f1fee1d9930> constant 97>
 <integer_cst 0x7f1fba8e12c0 type <pointer_type 0x7f20353fc540> constant 25>
 <integer_cst 0x7f1fba8e1680 type <pointer_type 0x7f20353fc540> constant 33>
 <integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
 <integer_cst 0x7f1f180634e0 type <pointer_type 0x7f1edda427e0 LookupGenericOp>
constant 0>
 <integer_cst 0x7f1fb28978e0 type <pointer_type 0x7f207af33c78
nsMallocSizeOfFun> constant 0>
 <integer_cst 0x7f1fb28978e0 type <pointer_type 0x7f207af33c78
nsMallocSizeOfFun> constant 0>
 <integer_cst 0x7f1fa8ab4780 type <pointer_type 0x7f2078d86bd0 InitDataFunc>
constant 0>
 <integer_cst 0x7f204e3d0880 type <pointer_type 0x7f1fee180540> constant 201>
 <integer_cst 0x7f1fbafd5a60 type <pointer_type 0x7f1ef3fc9498> constant 0>
 <integer_cst 0x7f1fe63de860 type <pointer_type 0x7f205716f9d8 destroyOp>
constant 0>
 <integer_cst 0x7f1fe63de860 type <pointer_type 0x7f205716f9d8 destroyOp>
constant 0>
 <integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
 <integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
 <integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
 <integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
 <integer_cst 0x7f20471da2c0 type <pointer_type 0x7f1fee1d9000> constant 161>

Martin, for 4.9 we can probably turn call to NULL into builtin_trap or
builtin_unreachable (not
sure if the second is fine, but it would result in better code).
I wonder however from where the non-NULL constants are comming? Isn't it some
bug in ipa-prop
that picks complete garbage? That may be possible wrong code issue...

I will commit patch tomorrow morning.
Honza

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-02-20 15:47:32 UTC ---
Author: hubicka
Date: Wed Feb 20 15:47:21 2013
New Revision: 196177

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

    PR tree-optimization/56265
    * ipa-prop.c (ipa_make_edge_direct_to_target): Fixup callgraph when target
is
    referenced for firs ttime.
    * testsuite/g++.dg/ipa/devirt-11.C: New testcase.

Added:
    trunk/gcc/testsuite/g++.dg/ipa/devirt-11.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-prop.c
    trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[hubicka at gcc dot gnu.org]

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

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

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

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-02-20 21:01:15 UTC ---
Fixed now.

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

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

--- Comment #11 from Martin Jambor <jamborm at gcc dot gnu.org> 2013-04-25 17:27:00 UTC ---
(In reply to comment #8)
> 
> Martin, for 4.9 we can probably turn call to NULL into builtin_trap or
> builtin_unreachable (not
> sure if the second is fine, but it would result in better code).
> I wonder however from where the non-NULL constants are comming? Isn't it some
> bug in ipa-prop
> that picks complete garbage? That may be possible wrong code issue...
> 
> I will commit patch tomorrow morning.
> Honza

I have looked at all 11 occurrences of these discovered calls to
non-functions and traced these values in the dumped jump functions and
it all seemed legitimate and fine.

Moreover, I have looked at actual IL of functions where the value was
passed in aggregate jump functions and it turned out the aggregate was
a C++ member pointers where one field is overloaded and can hold
either a pointer to a non-virtual method or an index to VMT if the
method is virtual.  

So yes, I'm in favor of turning the calls into builtin_trap or
builtin_unreachable.  Not sure which one.  How do I get their call
graph nodes?

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[hubicka at ucw dot cz]

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

--- Comment #12 from Jan Hubicka <hubicka at ucw dot cz> 2013-04-25 20:52:39 UTC ---
> So yes, I'm in favor of turning the calls into builtin_trap or
> builtin_unreachable.  Not sure which one.  How do I get their call
> graph nodes?

cgraph_get_create_node (builtin_decl_implicit (BUILT_IN_UNREACHABLE), 0);

Honza

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Redirecting to builtin_unreachable committed as revision 198926.