This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ICE's with -fgimple
- From: Richard Biener <rguenther at suse dot de>
- To: Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 20 Dec 2016 09:45:27 +0100 (CET)
- Subject: Re: ICE's with -fgimple
- Authentication-results: sourceware.org; auth=none
- References: <CAAgBjMk5AO5-9xfiC2FS-txKnh6odCz5W=-3TAWMV5uSDNnmNw@mail.gmail.com>
On Sun, 18 Dec 2016, Prathamesh Kulkarni wrote:
> Hi,
> I observed a couple of similar ICE's with -fgimple for a function
> having startwith.
>
> eg:
> void __GIMPLE (startwith ("ccp1")) foo ()
> {
> return;
> }
>
> Compiling with -fgimple -O works fine however removing -O causes the
> following ICE:
> foo.c:7:1: internal compiler error: in expand, at cgraphunit.c:2054
> }
> ^
> 0x7d4b5c cgraph_node::expand()
> ../../gcc/gcc/cgraphunit.c:2054
> 0x7d5852 output_in_order
> ../../gcc/gcc/cgraphunit.c:2244
> 0x7d5bfd symbol_table::compile()
> ../../gcc/gcc/cgraphunit.c:2488
> 0x7d86e2 symbol_table::compile()
> ../../gcc/gcc/cgraphunit.c:2558
> 0x7d86e2 symbol_table::finalize_compilation_unit()
>
> The following ICE is observed when startwith is set to some of the
> later passes even with -O,
> starting with fre3 like vrp1, pre, strlen (but few passes after fre3
> like thread1, dce2 don't cause ICE).
>
> foo.c: In function ‘foo’:
> foo.c:7:1: internal compiler error: in expand, at cgraphunit.c:2054
> }
> ^
> 0x7d4b5c cgraph_node::expand()
> ../../gcc/gcc/cgraphunit.c:2054
> 0x7d6217 expand_all_functions
> ../../gcc/gcc/cgraphunit.c:2137
> 0x7d6217 symbol_table::compile()
> ../../gcc/gcc/cgraphunit.c:2494
> 0x7d86e2 symbol_table::compile()
> ../../gcc/gcc/cgraphunit.c:2558
> 0x7d86e2 symbol_table::finalize_compilation_unit()
> ../../gcc/gcc/cgraphunit.c:2584
That's an "imperfection" with the pass manager integration (you'll
see similar ICEs when starswith picks a pass inside the loop pipeline
for example). If you fix the expansion issue you'll still run into
the fact that expand requires PROP_gimple_lvec for example and that
the provider is not executed.
"Fixing" that correctly requires some re-thinking of how we
schedule passes in general, but for the moment the following patch
works for me...
(testing)
Richard.
2016-12-20 Richard Biener <rguenther@suse.de>
* passes.c (execute_one_pass): Handle going out of SSA w/o
hitting pass_startwith. Handle skipping property providers.
* gcc.dg/gimplefe-19.c: New testcase.
Index: gcc/passes.c
===================================================================
--- gcc/passes.c (revision 243738)
+++ gcc/passes.c (working copy)
@@ -2321,7 +2324,10 @@ execute_one_pass (opt_pass *pass)
&& (cfun->curr_properties & PROP_ssa))
{
size_t namelen = strlen (pass->name);
- if (! strncmp (pass->name, cfun->pass_startwith, namelen))
+ /* We have to at least start when we leave SSA. */
+ if (pass->properties_destroyed & PROP_ssa)
+ cfun->pass_startwith = NULL;
+ else if (! strncmp (pass->name, cfun->pass_startwith, namelen))
{
/* The following supports starting with the Nth invocation
of a pass (where N does not necessarily is equal to the
@@ -2338,6 +2344,9 @@ execute_one_pass (opt_pass *pass)
return true;
}
}
+ /* And also run any property provider. */
+ else if (pass->properties_provided != 0)
+ ;
else
return true;
}
Index: gcc/testsuite/gcc.dg/gimplefe-19.c
===================================================================
--- gcc/testsuite/gcc.dg/gimplefe-19.c (revision 0)
+++ gcc/testsuite/gcc.dg/gimplefe-19.c (working copy)
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple" } */
+
+void __GIMPLE (startwith ("ccp1")) foo ()
+{
+ return;
+}