public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
@ 2012-12-23 11:04 zsojka at seznam dot cz
2012-12-26 22:20 ` [Bug middle-end/55797] " pinskia at gcc dot gnu.org
` (12 more replies)
0 siblings, 13 replies; 14+ messages in thread
From: zsojka at seznam dot cz @ 2012-12-23 11:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Bug #: 55797
Summary: [4.8 Regression] ICE: verify_cgraph_node failed: edge
has no corresponding call_stmt
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: zsojka@seznam.cz
Created attachment 29034
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29034
reduced testcase
Compiler output:
$ gcc -O -fno-guess-branch-probability -fno-tree-forwprop
--param=early-inlining-insns=176 testcase.C
testcase.C: In destructor 'intrusive_ptr<T>::~intrusive_ptr() [with T =
file_info]':
testcase.C:15:8: error: edge intrusive_ptr<T>::~intrusive_ptr() [with T =
file_info]->intrusive_ptr<T>::~intrusive_ptr() [with T = file_info] has no
corresponding call_stmt
struct file_info
^
# .MEM = VDEF <.MEM>
intrusive_ptr<file_info>::~intrusive_ptr (.MEM_6);
_ZN13intrusive_ptrI9file_infoED2Ev/594 (intrusive_ptr<T>::~intrusive_ptr()
[with T = file_info]) @0x7f1266fe5000
Type: function
Visibility: weak artificial
References: __gxx_personality_v0/13 (addr)
Referring:
Function intrusive_ptr<T>::~intrusive_ptr() [with T = file_info]/594 is
inline copy in intrusive_ptr<T>::~intrusive_ptr() [with T = file_info]/5
Clone of _ZN13intrusive_ptrI9file_infoED2Ev/600
Availability: local
Function flags: analyzed body local finalized
Called by: _ZN13intrusive_ptrI9file_infoED2Ev/5 (1.00 per call) (inlined)
(can throw external)
Calls: _ZN13intrusive_ptrI9file_infoED2Ev/600 (inlined) (1.00 per call) (can
throw external) _ZdlPv/14 (1.00 per call)
_ZN13intrusive_ptrI9file_infoED2Ev/598 (inlined) (1.00 per call) (can throw
external) _ZdlPv/14 (1.00 per call) _ZN12section_infoD2Ev/595 (inlined) (1.00
per call)
testcase.C:15:8: internal compiler error: verify_cgraph_node failed
0x861a9a verify_cgraph_node(cgraph_node*)
/mnt/svn/gcc-trunk/gcc/cgraph.c:2586
0xc27d36 expand_call_inline
/mnt/svn/gcc-trunk/gcc/tree-inline.c:3878
0xc27d36 gimple_expand_calls_inline
/mnt/svn/gcc-trunk/gcc/tree-inline.c:4147
0xc27d36 optimize_inline_calls(tree_node*)
/mnt/svn/gcc-trunk/gcc/tree-inline.c:4301
0x12ce0e6 inline_transform(cgraph_node*)
/mnt/svn/gcc-trunk/gcc/ipa-inline-transform.c:418
0xae4597 execute_one_ipa_transform_pass
/mnt/svn/gcc-trunk/gcc/passes.c:2177
0xae4597 execute_all_ipa_transforms()
/mnt/svn/gcc-trunk/gcc/passes.c:2213
0x866378 expand_function
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1634
0x868156 expand_all_functions
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1745
0x868156 compile()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2043
0x8687f9 finalize_compilation_unit()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2120
0x67eaee cp_write_global_declarations()
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:4291
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.
$ /mnt/svn/gcc-trunk/binary-latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-194694-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-194694-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.8.0 20121222 (experimental) (GCC)
Tested revisions:
r194694 - crash
4.7 r191640 - OK
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
@ 2012-12-26 22:20 ` pinskia at gcc dot gnu.org
2012-12-30 10:54 ` mpolacek at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2012-12-26 22:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.8.0
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
2012-12-26 22:20 ` [Bug middle-end/55797] " pinskia at gcc dot gnu.org
@ 2012-12-30 10:54 ` mpolacek at gcc dot gnu.org
2012-12-30 12:16 ` mpolacek at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2012-12-30 10:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-12-30
CC| |mpolacek at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> 2012-12-30 10:54:03 UTC ---
Confirmed.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
2012-12-26 22:20 ` [Bug middle-end/55797] " pinskia at gcc dot gnu.org
2012-12-30 10:54 ` mpolacek at gcc dot gnu.org
@ 2012-12-30 12:16 ` mpolacek at gcc dot gnu.org
2013-01-07 15:44 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2012-12-30 12:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> 2012-12-30 12:16:15 UTC ---
Started with http://gcc.gnu.org/viewcvs?view=revision&revision=193157
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (2 preceding siblings ...)
2012-12-30 12:16 ` mpolacek at gcc dot gnu.org
@ 2013-01-07 15:44 ` rguenth at gcc dot gnu.org
2013-01-08 13:51 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-07 15:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (3 preceding siblings ...)
2013-01-07 15:44 ` rguenth at gcc dot gnu.org
@ 2013-01-08 13:51 ` rguenth at gcc dot gnu.org
2013-01-08 14:25 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-08 13:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-08 13:50:58 UTC ---
Eh, we do totally crazy (recursive) inlining here ...
struct section_info
{
intrusive_ptr < section_info > parent;
};
struct file_info
{
intrusive_ptr < file_info > parent;
intrusive_ptr < section_info > switched_section;
};
so the simple
void
start_file (void)
{
intrusive_ptr < file_info > parent;
}
creates and destroys the graph of file_info / section_info nodes
with the edges represented by intrusive_ptr's.
void start_file() ()
{
...
<bb 2>:
_5 = parent.px;
if (_5 != 0B)
goto <bb 3>;
else
goto <bb 1041> (<L3>);
<bb 3>:
_6 = &_5->switched_section;
_7 = _6->px;
if (_7 != 0B)
goto <bb 4>;
else
goto <bb 6> (<L1>);
<bb 4>:
section_info::~section_info (_7);
<bb 5>:
operator delete (_7);
...
and 1000 calls follow.
I wonder why we need such high early-inlin-insns number and for lower we hit:
else if ((n = num_calls (callee)) != 0
&& growth * (n + 1) > PARAM_VALUE (PARAM_EARLY_INLINING_INSNS))
{
if (dump_file)
fprintf (dump_file, " will not early inline: %s/%i->%s/%i, "
"growth %i exceeds --param early-inlining-insns "
"divided by number of calls\n",
xstrdup (cgraph_node_name (e->caller)), e->caller->uid,
xstrdup (cgraph_node_name (callee)), callee->uid,
growth);
want_inline = false;
}
of which I cannot make very much sense. Why should the number of calls
in callee(!) times the growth matter? Shouldn't this be the number
of times the caller calls callee? And why even that? We've gone completely
away from the "consider only if all calls can be inlined" way of early
inline operation!
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (4 preceding siblings ...)
2013-01-08 13:51 ` rguenth at gcc dot gnu.org
@ 2013-01-08 14:25 ` rguenth at gcc dot gnu.org
2013-01-23 13:29 ` hubicka at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-08 14:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-08 14:24:59 UTC ---
Solution to put off recursive inlining through iteration:
Index: ipa-inline.c
===================================================================
--- ipa-inline.c (revision 195014)
+++ ipa-inline.c (working copy)
@@ -1951,7 +1951,9 @@ early_inline_small_functions (struct cgr
if (!can_early_inline_edge_p (e))
continue;
- if (cgraph_edge_recursive_p (e))
+ if (cgraph_edge_recursive_p (e)
+ || !DECL_STRUCT_FUNCTION
+ (callee->symbol.decl)->always_inline_functions_inlined)
{
if (dump_file)
fprintf (dump_file, " Not inlining: recursive call.\n");
as we process functions in DFS order any not already processed function
is in a callgraph cycle. This doesn't fix the overzealeous inlining via
the iteration for the testcase though as we still grow in calls quadratically
(we never hit a direct recursive call when inlining the recursive
sub-callgraph).
That is, early inlining completely misses the graph topology hints
(never inline a SCC entry edge, etc.)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (5 preceding siblings ...)
2013-01-08 14:25 ` rguenth at gcc dot gnu.org
@ 2013-01-23 13:29 ` hubicka at gcc dot gnu.org
2013-01-23 13:38 ` hubicka at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-01-23 13:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-23 13:28:35 UTC ---
Path to disable early inliner iteation is posted to
gcc.gnu.org/ml/gcc-patches/2013-01/msg01138.html
The ICE happens in IPA inlining rather than in early inliner.
I am looking into it.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (6 preceding siblings ...)
2013-01-23 13:29 ` hubicka at gcc dot gnu.org
@ 2013-01-23 13:38 ` hubicka at gcc dot gnu.org
2013-01-23 13:49 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-01-23 13:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-23 13:38:16 UTC ---
The patch in Comment #4 should not have any effect (and indeed the test does
not fire for me on the testcase). can_early_inline predicate already test that
the callee is in SSA form and we do into-ssa just before early inlining. So the
functions not processed yet in the topological order are not in SSA form.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (7 preceding siblings ...)
2013-01-23 13:38 ` hubicka at gcc dot gnu.org
@ 2013-01-23 13:49 ` jakub at gcc dot gnu.org
2013-01-23 13:57 ` hubicka at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-01-23 13:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-23 13:49:17 UTC ---
For 4.9, wouldn't it be better to get all functions through the very early
passes (up to and including build_ssa (or one or three passes after it,
but before pass_inline_parameters)), then in another loop run the rest of early
passes (i.e. inline_parameters/einline, ..., eipa_sra, ...,
pass_inline_parameters) and then the normal IPA queue? The amount of issues we
have with functions not in SSA form yet, whether it is in early inliner, or
eipa_sra, etc. is big.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (8 preceding siblings ...)
2013-01-23 13:49 ` jakub at gcc dot gnu.org
@ 2013-01-23 13:57 ` hubicka at gcc dot gnu.org
2013-01-23 14:00 ` hubicka at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-01-23 13:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-23 13:56:44 UTC ---
This is not really issue with early inliner confused with function not being in
SSA form. But for aid of esra, we can do that at expense of increasing of peak
memory use - the SSA form is quite bloated just after built and early passes
gets it noticeably smaller, so we may need to schedule another DCE pass or so.
The problem here is however saving body of
file_info::~file_info() (struct file_info * const this)
{
struct intrusive_ptr * _2;
struct intrusive_ptr * _5;
struct intrusive_ptr * _7;
struct section_info * _9;
<bb 2>:
_2 = &this_1(D)->switched_section;
_9 = _2->px;
if (_9 != 0B)
goto <bb 3>;
else
goto <bb 5> (<L2>);
<bb 3>:
section_info::~section_info (_9);
<bb 4>:
operator delete (_9);
<L2>:
_5 = &this_1(D)->parent;
intrusive_ptr<file_info>::~intrusive_ptr (_5);
return;
<L1>:
_7 = &this_1(D)->parent;
intrusive_ptr<file_info>::~intrusive_ptr (_7);
resx 1
}
The basic block <L1> in unreachable, but for some reason it is not removed
prior inlining. save_function_body must run delete_unreachable_blocks in order
to update SSA after copying and that one gets rid of the call. It updates the
node itself, but not the clones. I will add code to update clones.
I suppose this is because
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (9 preceding siblings ...)
2013-01-23 13:57 ` hubicka at gcc dot gnu.org
@ 2013-01-23 14:00 ` hubicka at gcc dot gnu.org
2013-01-23 14:20 ` hubicka at gcc dot gnu.org
2013-02-08 11:30 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-01-23 14:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-23 14:00:23 UTC ---
Just for record, I do not recall any issues with early inliner being run in
parallel with into-SSA. As a simple inliner working in topological order, it
really does not care about functions not processed yet.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (10 preceding siblings ...)
2013-01-23 14:00 ` hubicka at gcc dot gnu.org
@ 2013-01-23 14:20 ` hubicka at gcc dot gnu.org
2013-02-08 11:30 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: hubicka at gcc dot gnu.org @ 2013-01-23 14:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> 2013-01-23 14:19:51 UTC ---
I am testing the following patch. It is a side case where we save function body
but the function we save the body of becomes unnecesary as a result of dead
block removal during inlining that is caused by ipa-pure-const proving function
nothorw.
We get it almost right by removing the unnecesary clone after saving, but we
forget about the edge.
Index: cgraphclones.c
===================================================================
--- cgraphclones.c (revision 195370)
+++ cgraphclones.c (working copy)
@@ -570,7 +570,10 @@ cgraph_remove_node_and_inline_clones (st
bool found = false;
if (node == forbidden_node)
- return true;
+ {
+ cgraph_remove_edge (node->callers);
+ return true;
+ }
for (e = node->callees; e; e = next)
{
next = e->next_callee;
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
` (11 preceding siblings ...)
2013-01-23 14:20 ` hubicka at gcc dot gnu.org
@ 2013-02-08 11:30 ` jakub at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-02-08 11:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-08 11:29:40 UTC ---
Honza, please be more careful with PR numbers ;)
I believe this is fixed now by:
Author: hubicka
Date: Tue Feb 5 09:11:53 2013
New Revision: 195750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195750
Log:
PR tree-optimization/r55789
* cgraphclones.c (cgraph_remove_node_and_inline_clones): Remove
the dead call anyway.
* g++.dg/torture/pr55789.C: New testcase.
Added:
trunk/gcc/testsuite/g++.dg/torture/pr55789.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphclones.c
trunk/gcc/testsuite/ChangeLog
Author: hubicka
Date: Tue Feb 5 09:13:48 2013
New Revision: 195751
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195751
Log:
PR tree-optimization/55789
* g++.dg/tree-ssa/inline-1.C: Update max-inliner-iterations.
* g++.dg/tree-ssa/inline-2.C: Update max-inliner-iterations.
* g++.dg/tree-ssa/inline-3.C: Update max-inliner-iterations.
* g++.dg/ipa/inline-1.C: New testcase.
* g++.dg/ipa/inline-2.C: New testcase.
* g++.dg/ipa/inline-3.C: New testcase.
* params.def (PARAM_EARLY_INLINER_MAX_ITERATIONS): Drop to 1.
Added:
trunk/gcc/testsuite/g++.dg/ipa/inline-1.C
trunk/gcc/testsuite/g++.dg/ipa/inline-2.C
trunk/gcc/testsuite/g++.dg/ipa/inline-3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-1.C
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-2.C
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-3.C
Author: hubicka
Date: Tue Feb 5 15:23:56 2013
New Revision: 195758
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195758
Log:
PR tree-optimization/55789
* g++.dg/tree-ssa/inline-1.C: Update max-inliner-iterations.
* g++.dg/tree-ssa/inline-2.C: Update max-inliner-iterations.
* g++.dg/tree-ssa/inline-3.C: Update max-inliner-iterations.
* g++.dg/ipa/inline-1.C: New testcase.
* g++.dg/ipa/inline-2.C: New testcase.
* g++.dg/ipa/inline-3.C: New testcase.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ipa/inline-1.C
trunk/gcc/testsuite/g++.dg/tree-ssa/inline-3.C
Author: jakub
Date: Thu Feb 7 10:45:12 2013
New Revision: 195844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195844
Log:
PR tree-optimization/55789
* g++.dg/ipa/inline-3.C: Use cleanup-ipa-dump instead of
cleanup-tree-dump.
* gcc.dg/tree-ssa/inline-3.c: Add
--param max-early-inliner-iterations=2 option.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ipa/inline-3.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/inline-3.c
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-02-08 11:30 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-23 11:04 [Bug middle-end/55797] New: [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt zsojka at seznam dot cz
2012-12-26 22:20 ` [Bug middle-end/55797] " pinskia at gcc dot gnu.org
2012-12-30 10:54 ` mpolacek at gcc dot gnu.org
2012-12-30 12:16 ` mpolacek at gcc dot gnu.org
2013-01-07 15:44 ` rguenth at gcc dot gnu.org
2013-01-08 13:51 ` rguenth at gcc dot gnu.org
2013-01-08 14:25 ` rguenth at gcc dot gnu.org
2013-01-23 13:29 ` hubicka at gcc dot gnu.org
2013-01-23 13:38 ` hubicka at gcc dot gnu.org
2013-01-23 13:49 ` jakub at gcc dot gnu.org
2013-01-23 13:57 ` hubicka at gcc dot gnu.org
2013-01-23 14:00 ` hubicka at gcc dot gnu.org
2013-01-23 14:20 ` hubicka at gcc dot gnu.org
2013-02-08 11:30 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).