[Bug c++/55823] New: ice in inline_call, at ipa-inline-transform.c:270

[Bug c++/55823] New: ice in inline_call, at ipa-inline-transform.c:270

[dcb314 at hotmail dot com]

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

             Bug #: 55823
           Summary: ice in inline_call, at ipa-inline-transform.c:270
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dcb314@hotmail.com


Created attachment 29056
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29056
gzipped C source code

I just tried to compile the package audacity-2.0.2-2
on gcc-4.8 trunk dated 20121227 on an AMD x86_64 box.

The compiler said

widgets/AButton.cpp:395:1: internal compiler error: in inline_call, at
ipa-inline-transform.c:270
 }
 ^
0xec3fc4 inline_call(cgraph_edge*, bool, vec<cgraph_edge*, va_heap, vl_ptr>*,
int*, bool)
    ../../src/trunk/gcc/ipa-inline-transform.c:266
0xec356a inline_small_functions
    ../../src/trunk/gcc/ipa-inline.c:1614
0xec356a ipa_inline
    ../../src/trunk/gcc/ipa-inline.c:1795
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.


Preprocessed source code attached. Flag -O3 required.

This might be related to bug # 55683

[Bug c++/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
   Target Milestone|---                         |4.8.0
            Summary|ice in inline_call, at      |[4.8 Regression] ice in
                   |ipa-inline-transform.c:270  |inline_call, at
                   |                            |ipa-inline-transform.c:270

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-31 10:34:30 UTC ---
Reducing.

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-12-31
          Component|c++                         |tree-optimization
      Known to work|                            |4.7.0
     Ever Confirmed|0                           |1
      Known to fail|                            |4.8.0

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-31 11:57:15 UTC ---
Reduced testcase:
class wxPaintEvent {  };
struct wxDCBase
{
  wxDCBase ();
  virtual int GetLayoutDirection() const{}
  virtual void SetLayoutDirection(int){}
};
struct wxWindowDC  : public wxDCBase {};
struct wxBufferedDC  : public wxDCBase
{
  void Init(wxDCBase*dc) {
    InitCommon(dc);
  }
  void InitCommon(wxDCBase*dc) {
    if (dc)
      SetLayoutDirection(dc->GetLayoutDirection());
  }
};
struct wxBufferedPaintDC  : public wxBufferedDC {
  wxBufferedPaintDC() {
    Init(&m_paintdc);
  }
 wxWindowDC m_paintdc;
};
void  OnPaint(wxPaintEvent & event) {
  wxBufferedPaintDC dc;
}

Re: [Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[Jan Hubicka]

This is the usual problem of devirt benefit predicting more devirtualization
than inline-transform actually doing.  This time it seems to be related to fact
that we first clone the function and propagate &m_paintdc but somehow fail to
recognize the devirtualizatoin oppurtunities again...

Honza

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-31 12:00:56 UTC ---
(In reply to comment #0)
> This might be related to bug # 55683

Most likely is because -fno-indirect-inlining helps.  CCing Martin because of
that.

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka <hubicka at ucw dot cz> 2013-01-01 23:32:27 UTC ---
This is the usual problem of devirt benefit predicting more devirtualization
than inline-transform actually doing.  This time it seems to be related to fact
that we first clone the function and propagate &m_paintdc but somehow fail to
recognize the devirtualizatoin oppurtunities again...

Honza

Re: [Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[Jan Hubicka]

ipa-cp is behaving funny here. It clones InitCommon so THIS pointer's binfo is
known to enable devirtualization of SetLayoutDirection.

It doesn't devirtualize GetLayoutDirection because it works on per-argument
basis.  This is stupid: obviously whenever THIS binfo is known also DC binfo is
known, so we should propagate both into the clone. This is missed optimization
relative to previous ipa-cp implementation and I think relatively serious one -
it is very common that more than one argument is constant.
Martin, can you take a look?

Still don't know exactly why we miss the devirtualization after inlining.

Honza

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> 2013-01-02 00:10:52 UTC ---
ipa-cp is behaving funny here. It clones InitCommon so THIS pointer's binfo is
known to enable devirtualization of SetLayoutDirection.

It doesn't devirtualize GetLayoutDirection because it works on per-argument
basis.  This is stupid: obviously whenever THIS binfo is known also DC binfo is
known, so we should propagate both into the clone. This is missed optimization
relative to previous ipa-cp implementation and I think relatively serious one -
it is very common that more than one argument is constant.
Martin, can you take a look?

Still don't know exactly why we miss the devirtualization after inlining.

Honza

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[rguenth at gcc dot gnu.org]

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

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

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

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[hubicka at gcc dot gnu.org]

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

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

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-03 16:22:43 UTC ---
Hi,
the problem is that at the time ipa_get_indirect_edge_target is called from
devirt_benefit on _ZN12wxBufferedDC10InitCommonEP8wxDCBase.constprop.1/33 being
inlined it is seeing following info:
(gdb) p debug_tree (binfo)
 <tree_binfo 0x7ffff6db6138
    type <record_type 0x7ffff6dca348 wxWindowDC sizes-gimplified addressable
tree_2 needs-constructing type_5 BLK
        size <integer_cst 0x7ffff6c50dc0 constant 64>
        unit size <integer_cst 0x7ffff6c50de0 constant 8>
        align 64 symtab 0 alias set 5 canonical type 0x7ffff6dca348
        fields <field_decl 0x7ffff6db5b48 D.2218 type <record_type
0x7ffff6db9690 wxDCBase>
            ignored decl_6 BLK file /home/jan/t.C line 8 col 8 size
<integer_cst 0x7ffff6c50dc0 64> unit size <integer_cst 0x7ffff6c50de0 8>
            align 64 offset_align 128
            offset <integer_cst 0x7ffff6c50e00 constant 0>
            bit offset <integer_cst 0x7ffff6c50e80 constant 0> context
<record_type 0x7ffff6dca348 wxWindowDC> chain <type_decl 0x7ffff6db3cf0
wxWindowDC>> context <translation_unit_decl 0x7ffff6c69170 D.1>
        full-name "struct wxWindowDC"
        needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=0
interface-unknown
        pointer_to_this <pointer_type 0x7ffff6dd2d20> reference_to_this
<reference_type 0x7ffff6dd9540> chain <type_decl 0x7ffff6db3c38 wxWindowDC>>
    private tree_2>


(gdb) p debug_tree (otr_type)
 <record_type 0x7ffff6db9690 wxDCBase sizes-gimplified addressable tree_2
needs-constructing type_1 type_5 BLK
    size <integer_cst 0x7ffff6c50dc0 type <integer_type 0x7ffff6c6b0a8
bitsizetype> constant 64>
    unit size <integer_cst 0x7ffff6c50de0 type <integer_type 0x7ffff6c6b000
sizetype> constant 8>
    align 64 symtab 0 alias set 2 canonical type 0x7ffff6db9690
    fields <field_decl 0x7ffff6db5850 _vptr.wxDCBase
        type <pointer_type 0x7ffff6db01f8 type <pointer_type 0x7ffff6db00a8
__vtbl_ptr_type>
            sizes-gimplified public unsigned DI size <integer_cst
0x7ffff6c50dc0 64> unit size <integer_cst 0x7ffff6c50de0 8>
            align 64 symtab 0 alias set 3 canonical type 0x7ffff6db01f8>
        unsigned virtual DI file /home/jan/t.C line 2 col 8 size <integer_cst
0x7ffff6c50dc0 64> unit size <integer_cst 0x7ffff6c50de0 8>
        align 64 offset_align 128
        offset <integer_cst 0x7ffff6c50e00 constant 0>
        bit offset <integer_cst 0x7ffff6c50e80 constant 0> context <record_type
0x7ffff6db9690 wxDCBase>
        chain <type_decl 0x7ffff6db3ac8 wxDCBase type <record_type
0x7ffff6db9738 wxDCBase>
            used nonlocal decl_4 VOID file /home/jan/t.C line 3 col 1
            align 1 context <record_type 0x7ffff6db9690 wxDCBase> result
<record_type 0x7ffff6db9690 wxDCBase>
           >> context <translation_unit_decl 0x7ffff6c69170 D.1>
    full-name "struct wxDCBase"
    needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
    pointer_to_this <pointer_type 0x7ffff6db9930> reference_to_this
<reference_type 0x7ffff6dd2540> chain <type_decl 0x7ffff6db3a10 wxDCBase>>

(gdb) p anc_offset
$33 = 0

This leads to devirtualization.  It is because the info is known from function
itself. As noted earlier ipa-cp missed it for no valid reasons.

Now we inline and go to:
0x0000000000a9ce3b in update_indirect_edges_after_inlining (cs=0x7ffff6de62d8,
node=0x7ffff6dd3378, new_edges=0x7fffffffda20) at ../../gcc/ipa-prop.c:2284

0x0000000000a9ce3b in update_indirect_edges_after_inlining (cs=0x7ffff6de62d8,
node=0x7ffff6dd3378, new_edges=0x7fffffffda20) at ../../gcc/ipa-prop.c:2284
2284                  ici->offset += ipa_get_jf_ancestor_offset (jfunc);
(gdb) l
2279                  && !ipa_get_jf_ancestor_agg_preserved (jfunc))
2280                ici->param_index = -1;
2281              else
2282                {
2283                  ici->param_index = ipa_get_jf_ancestor_formal_id (jfunc);
2284                  ici->offset += ipa_get_jf_ancestor_offset (jfunc);
2285                }
2286            }

at this time the jump functions are updated for inlining into
_ZN17wxBufferedPaintDCC2Ev.constprop.0.
This time we cast to ancestor (if I get everything right) and the offset is
updated to 64.

Now try_make_edge_direct_virtual_call is called and it sees ANCESTOR jfunc and
at

2211      binfo = get_binfo_at_offset (binfo, ie->indirect_info->offset,
2212                                   ie->indirect_info->otr_type);

it passes the same binfo

 <tree_binfo 0x7ffff6db6138
    type <record_type 0x7ffff6dca348 wxWindowDC sizes-gimplified addressable
tree_2 needs-constructing type_5 BLK
        size <integer_cst 0x7ffff6c50dc0 constant 64>
        unit size <integer_cst 0x7ffff6c50de0 constant 8>
        align 64 symtab 0 alias set 5 canonical type 0x7ffff6dca348
        fields <field_decl 0x7ffff6db5b48 D.2218 type <record_type
0x7ffff6db9690 wxDCBase>
            ignored decl_6 BLK file /home/jan/t.C line 8 col 8 size
<integer_cst 0x7ffff6c50dc0 64> unit size <integer_cst 0x7ffff6c50de0 8>
            align 64 offset_align 128
            offset <integer_cst 0x7ffff6c50e00 constant 0>
            bit offset <integer_cst 0x7ffff6c50e80 constant 0> context
<record_type 0x7ffff6dca348 wxWindowDC> chain <type_decl 0x7ffff6db3cf0
wxWindowDC>> context <translation_unit_decl 0x7ffff6c69170 D.1>
        full-name "struct wxWindowDC"
        needs-constructor X() X(constX&) this=(X&) n_parents=1 use_template=0
interface-unknown
        pointer_to_this <pointer_type 0x7ffff6dd2d20> reference_to_this
<reference_type 0x7ffff6dd9540> chain <type_decl 0x7ffff6db3c38 wxWindowDC>>
    private tree_2>

but already combined offset 64.  This leads to nothing.

How this is supposed to work?
It is using jump functions of the call site we are seeing.

I am confused. I do not see how devirtualization/indirect call code can work
after we update jump functions to new context. In partiuclar what happens when
the parameter is constant?  It seems that the following code:

      if (jfunc->type == IPA_JF_PASS_THROUGH
          && ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
        {
          if (ici->agg_contents
              && !ipa_get_jf_pass_through_agg_preserved (jfunc))
            ici->param_index = -1;
          else
            ici->param_index = ipa_get_jf_pass_through_formal_id (jfunc);
        }
      else if (jfunc->type == IPA_JF_ANCESTOR)
        {
          if (ici->agg_contents
              && !ipa_get_jf_ancestor_agg_preserved (jfunc))
            ici->param_index = -1;
          else
            {
              ici->param_index = ipa_get_jf_ancestor_formal_id (jfunc);
              ici->offset += ipa_get_jf_ancestor_offset (jfunc);
            }
        }
      else
        /* Either we can find a destination for this edge now or never. */
        ici->param_index = -1;

will drop ici->param_index to -1 before we do any attempt to devirtualize so we
simply miss the information given.

Second it seems that the combining of offsets is wrong.  wxWindowDC is empty
wrapper
around wxDCBase. From where the offset is comming?

Honza

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-03 16:26:16 UTC ---
The following patch to devirtualize before updating jump functions solves the
testcase but I am not at all sure it is correct.
Index: ipa-prop.c
===================================================================
--- ipa-prop.c  (revision 194770)
+++ ipa-prop.c  (working copy)
@@ -2264,8 +2264,19 @@ update_indirect_edges_after_inlining (st

       param_index = ici->param_index;
       jfunc = ipa_get_ith_jump_func (top, param_index);
-      if (jfunc->type == IPA_JF_PASS_THROUGH
-         && ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
+
+      if (!flag_indirect_inlining)
+       ;
+      else if (ici->polymorphic)
+       new_direct_edge = try_make_edge_direct_virtual_call (ie, jfunc,
+                                                            new_root_info);
+      else
+       new_direct_edge = try_make_edge_direct_simple_call (ie, jfunc,
+                                                           new_root_info);
+      if (new_direct_edge)
+       ;
+      else if (jfunc->type == IPA_JF_PASS_THROUGH
+              && ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
        {
          if (ici->agg_contents
              && !ipa_get_jf_pass_through_agg_preserved (jfunc))
@@ -2291,13 +2302,6 @@ update_indirect_edges_after_inlining (st
       if (!flag_indirect_inlining)
        continue;

-      if (ici->polymorphic)
-       new_direct_edge = try_make_edge_direct_virtual_call (ie, jfunc,
-                                                            new_root_info);
-      else
-       new_direct_edge = try_make_edge_direct_simple_call (ie, jfunc,
-                                                           new_root_info);
-
       if (new_direct_edge)
        {
          new_direct_edge->indirect_inlining_edge = 1;

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-08 20:23:12 UTC ---
Author: hubicka
Date: Tue Jan  8 20:23:05 2013
New Revision: 195033

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

    PR tree-optimization/55823
    * ipa-prop.c (update_indirect_edges_after_inlining): Fix ordering issue.

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

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-09 09:07:24 UTC ---
We no longer ICE in the testcase. We still regress by missing devirtualization
in new ipa-cp implementation and I would like Martin to double check that the
right thing happens when combining the ancestor jump function.

No ICE, no wrong code, so no longer P1 I guess.

[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-09 09:32:21 UTC ---
Fixed instead.  Missed devirt is something completely different.