This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration


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

--- Comment #18 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-01-12 13:50:11 UTC ---
You're right, however in fact all redirections and updates should be
taking place already.  Either in inline_transform() for calls that are
in the function from the beginning of inlining or later when new ones
are added in copy_bb().

So I was looking for why this one did not and figured out that they
are original calls, cgraph_redirect_edge_call_stmt_to_callee() is called
on their edges but it returns immediately because of this condition:

cgraph_get_node (decl) == cgraph_get_node (e->callee->decl)

It is satisfied because the declaration in the IL is an alias, the
function returns and the alias decl stays in the IL.  But e->callee is
not the node that the alias cgraph_node aliases, it is another inline
clone instead.  And the aliased node is also scheduled to be inlined.

After it is inlined, the node is removed together with its alias nodes
and from that point on there is no cgraph_node for the alias
declaration and so when it is stumbled on another time, cgraph_node()
function creates a new one and the verifier explodes.

I therefore propose to remove the quoted condition from
cgraph_redirect_edge_call_stmt_to_callee().  It was originally added
by Jakub in his fix for PR 42508 with a comment (#4) saying:

"The cgraphunit.c hunk is only somewhat related, is not necessary to
fix this, I've just noticed that the function was still modifying
GIMPLE_CALL decl unnecessarily (and confusingly), when e->callee is an
inline clone of some cgraph node with same_body aliases and
GIMPLE_CALL calls the same_body alias."

Nevertheless, my patch in comment #16 is also OK (and would save a bit
of unnecessary work) because the call statement is not updated only if
it is not necessary because still the same old function is being
called, just through an alias of what is now an inline clone.

So Honza, what do you prefer?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]