[Bug middle-end/48585] New: [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[Bug middle-end/48585] New: [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

           Summary: [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed
                    to build
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com


On Linux/x86-64, revision 172296 gave

g++  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin ...

In member function
'_ZNSt5dequeIN10xalanc_1_814XalanNamespaceESaIS1_EE15_M_destroy_dataESt15_Deque_iteratorIS1_RS1_PS1_ES7_RKS2_.local.9351.constprop.15260':
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [/tmp/ccfA5AxM.ltrans4.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
specmake[3]: *** [Xalan] Error 1

Revision 172238 is OK.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.0

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2011-04-13 13:05:46 UTC ---
It is caused y revision 172257:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00452.html

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.04.13 13:39:18
         AssignedTo|unassigned at gcc dot       |jamborm at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #2 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-13 13:39:18 UTC ---
Confirmed. Let me have a look.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

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

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

--- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-13 14:55:48 UTC ---
Compilation segfaults in LTRANS stage on line 1738 in tree-inline.c
(the assert below) because the dereferenced dest is zero.

      /* Constant propagation on argument done during inlining
     may create new direct call.  Produce an edge for it.  */
      if ((!edge
       || (edge->indirect_inlining_edge
           && id->transform_call_graph_edges == CB_CGE_MOVE_CLONES))
      && (fn = gimple_call_fndecl (stmt)) != NULL)
    {
      struct cgraph_node *dest = cgraph_get_node (fn);

      /* We have missing edge in the callgraph.  This can happen
         when previous inlining turned an indirect call into a
         direct call by constant propagating arguments or we are
         producing dead clone (for further cloning).  In all
         other cases we hit a bug (incorrect node sharing is the
         most common reason for missing edges).  */
      gcc_assert (dest->needed || !dest->analyzed
              || dest->address_taken
                || !id->src_node->analyzed
              || !id->dst_node->analyzed);

fn is <function_decl 0x7ffff65d3300 __comp_dtor> 
id->transform_call_graph_edges is CB_CGE_MOVE_CLONES
calling cgraph_edge (id->dst_node, stmt) from within the debugger
(to get edge which it says is optimized out) returns NULL.

I'd rather avoid calling cgraph_get_create_node here, the node should
be created by whatever inserts it into the IL.  Let me check whether
the bug goes away if I disable IPA-CP first.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-13 15:38:56 UTC ---
And indeed it does.  Therefore I believe we should add it to the referenced set
of a clone in the WPA stage...?

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> 2011-04-15 09:22:36 UTC ---
> And indeed it does.  Therefore I believe we should add it to the referenced set
> of a clone in the WPA stage...?
Yes, we spoke on this some time ago - when propagating constant into function
we should
add reference and we also should remove references when promoting indirect call
to direct
to let the target to be optimized well.

Honza

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-15 17:48:01 UTC ---
Unfortunately it seems that cgraph_create_virtual_clone already does
that... so either this information is not actually used to create the
node in the LTRANS stage or it gets lost along the way.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-15 18:34:30 UTC ---
Well, I guess I should have verified this but it seems that
&__comp_dtor is not actually one of the constants propagated by
IPA-CP.  So we'll have to figure out where it actually comes from
first.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-20 17:24:04 UTC ---
Looking into this a bit more, this has probably nothing to do with
IPA-CP at all.  When I dump the body of the function being inlined I
get:

--------------------------------------------------
(gdb) call debug_function (id->src_fn, 0)
__base_ctor  (struct XalanDOMStringPool * const this, long unsigned int
theBlockSize, long unsigned int theBucketCount, long unsigned int
theBucketSize)
{
  struct XalanDOMStringHashTable * D.46218;
  struct XalanDOMStringAllocator * D.46217;

<bb 2>:
  this_1(D)->_vptr.XalanDOMStringPool =
&_ZTVN10xalanc_1_818XalanDOMStringPoolE[2];
  D.46217_2 = &this_1(D)->m_stringAllocator;
  __comp_ctor  (D.46217_2, theBlockSize_3(D));
  this_1(D)->m_stringCount = 0;
  D.46218_4 = &this_1(D)->m_hashTable;
  __comp_ctor  (D.46218_4, theBucketCount_5(D), theBucketSize_6(D));

<bb 3>:
  return;

<L0>:
  __comp_dtor  (D.46217_2);
  resx 1

}
--------------------------------------------------

Yet when I look up the function in the pre-LTO release_ssa dump, I
see:

--------------------------------------------------

xalanc_1_8::XalanDOMStringPool::XalanDOMStringPool(unsigned long, unsigned
long, unsigned long) (struct XalanDOMStringPool * const this, block_size_type
theBlockSize, bucket_count_type theBucketCount, bucket_size_type theBucketSize)
{
  struct XalanDOMStringHashTable * D.22278;
  struct AllocatorType * D.22277;

<bb 2>:
  this_1(D)->_vptr.XalanDOMStringPool =
&_ZTVN10xalanc_1_818XalanDOMStringPoolE[2];
  D.22277_2 = &this_1(D)->m_stringAllocator;
  xalanc_1_8::XalanDOMStringAllocator::XalanDOMStringAllocator (D.22277_2,
theBlockSize_3(D));
  this_1(D)->m_stringCount = 0;
  D.22278_4 = &this_1(D)->m_hashTable;
  xalanc_1_8::XalanDOMStringHashTable::XalanDOMStringHashTable (D.22278_4,
theBucketCount_5(D), theBucketSize_6(D));

<bb 3>:
  return;

<L0>:
  xalanc_1_8::XalanDOMStringAllocator::~XalanDOMStringAllocator (D.22277_2);
  resx 1

}

The call to the destructor is already there, it almost looks like we
lost the part of the call graph that represents it somewhere in
streaming, WPA, partitioning or streaming for LTRANS...

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-20 18:17:14 UTC ---
Actually, IPA-CP is clearly involved, the function we're inlinig to
is:

(gdb) call debug_generic_expr(id->dst_fn)
_ZN10xalanc_1_818XalanDOMStringPoolC2Emmm.constprop.15285

Looking at the WPA cgraph dump, it is apparent that also the src_fn is
cloned by IPA-CP.  However, it remains to be seen why the original and
not the clone is being inlined here.  When I look at the ASM name of
the src function:

(gdb) call debug_generic_expr(decl_assembler_name(id->src_fn))
_ZN10xalanc_1_818XalanDOMStringPoolC2Emmm.9230

And then it up in WPA cgraph_node, it shows no callers or callees at
all:

__base_ctor /77004(-1) @0x7f91ca86f000 (asm:
_ZN10xalanc_1_818XalanDOMStringPoolC2Emmm) availability:n
ot_available local prevailing_def_ironly finalized
  called by:
  calls:
  References:
  Refering this function:
  aliases & thunks: __comp_ctor /77005 (asm:
_ZN10xalanc_1_818XalanDOMStringPoolC1Emmm)

So I don't quite understand how it can be scheduled to be inlined...

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-04-21 11:07:03 UTC ---
Hmm, I am not sure I follow here.  So the bug seems to be that
1) ipa-cp produces a clone
2) somehow after WPA we inline the original function, not the clone
right?

How this can lead to more direct calls?  Is the call represented as call to
clone in the callgraph?  If not, I guess ipa-cp produced clone but kept
original copy around and we are inlining real cal to original copy. This can
happen.

If callgraph has call to clone properly represented, but somehow we end up
inlining original, I would expect the original to have monotonously fewer
direct calls, so we should have the call destination we discovered during
inlining around...

Only case i can think this might legally happen is inlining producing direct
call via devirtualization from folding.  In this case cgraph don't see the
posibility and we need to add the cgraph node (we already checked that the
destination is not static function in other unit)

Honza

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-21 13:16:26 UTC ---
(In reply to comment #10)
> Hmm, I am not sure I follow here.  So the bug seems to be that
> 1) ipa-cp produces a clone
> 2) somehow after WPA we inline the original function, not the clone
> right?
> 
> How this can lead to more direct calls?

I don't think there are any new calls, just look at the dumps of
release_ssa and then in inline-transform, the calls match.

It seems to me that we loose all edges of this node and then try to
re-create them during inline-transform which fails if one of the
callees is in a different partition.

Why we loose all the edges (both callers and calles) is still a
mystery to me.  I'll debug this again after updating svn to todays
revision.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #12 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-21 18:02:54 UTC ---
OK, I've been wrong on many accounts above but at least I know what is
going on now.  The segfault happens while materializing cones, not
while inlining.  And we're materializing a clone that is itself
unreachable, it's there only to facilitate materialization of its own
inline clones.  Those have no edges so we did not find any.  Moreover,
creating edges for it is entirely unnecessary too (nd can lead to
ICEs, as we now know.

By the way, in this particular case we could not find a node for the
decl because it was a same_body alias but since all clones that will
survive will redirect the call according the edge anyway, it can in
theory happen even without them.  Nevertheless, the fact that
same_alias nodes apparently get lost with LTO, the first condition in
cgraph_redirect_edge_call_stmt_to_callee will not have any effect and
the calls will be redirected to the real decl from the same body
alias.

Anyway, my (untested) roposed fix is most probably this:

Index: gcc/tree-inline.c
===================================================================
--- gcc/tree-inline.c   (revision 172817)
+++ gcc/tree-inline.c   (working copy)
@@ -1725,6 +1725,7 @@ copy_bb (copy_body_data *id, basic_block
              if ((!edge
                   || (edge->indirect_inlining_edge
                       && id->transform_call_graph_edges ==
CB_CGE_MOVE_CLONES))
+                 && id->dst_node->reachable
                  && (fn = gimple_call_fndecl (stmt)) != NULL)
                { 
                  struct cgraph_node *dest = cgraph_get_node (fn);

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[hubicka at ucw dot cz]

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

--- Comment #13 from Jan Hubicka <hubicka at ucw dot cz> 2011-04-22 08:45:38 UTC ---
> Index: gcc/tree-inline.c
> ===================================================================
> --- gcc/tree-inline.c   (revision 172817)
> +++ gcc/tree-inline.c   (working copy)
> @@ -1725,6 +1725,7 @@ copy_bb (copy_body_data *id, basic_block
>               if ((!edge
>                    || (edge->indirect_inlining_edge
>                        && id->transform_call_graph_edges ==
> CB_CGE_MOVE_CLONES))
> +                 && id->dst_node->reachable

Reachable flag is not really maningful in this aspect.  You probably want
analyzed flag here.

As my recolection goes, I remember I had problems with missing edges in the
clones being materialized for later materialization alone.  The problem was
that edges gets redirected to new statement when they exists but when
they not, they are not updated and we need to update the statements in
clones that are in callgraph.
Back then I decided to temporarily create the edges so redirection mechanizm
works.  I think since then we fixed it properly by looking for edges in the
descendands even if edge does not exist, so I guess the fix above should work.

Thanks for looking into that!

Honza
>                   && (fn = gimple_call_fndecl (stmt)) != NULL)
>                 { 
>                   struct cgraph_node *dest = cgraph_get_node (fn);
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #14 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-22 12:36:28 UTC ---
OK, I have submitted a patch using the analyzed flag to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01855.html

I will commit it momentarily.

Thanks,

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #15 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-22 12:52:32 UTC ---
Author: jamborm
Date: Fri Apr 22 12:52:30 2011
New Revision: 172858

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172858
Log:
2011-04-22  Martin Jambor  <mjambor@suse.cz>

    PR middle-end/48585
    * tree-inline.c (copy_bb): Create new edges only for analyzed
    nodes.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-inline.c

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

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

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

--- Comment #16 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-22 13:01:07 UTC ---
Fixed.

[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #17 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-26 08:48:25 UTC ---
*** Bug 48683 has been marked as a duplicate of this bug. ***