https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84741
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dmalcolm at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't think this is a regression, the __RTL stuff has been introduced in GCC
7. And, there are infinite number of ways to get ICEs with __RTL or __GIMPLE
by just adding invalid IL, __RTL and __GIMPLE are just meant for testing the
compiler.
The reason this ICEs is that if we call run_rtl_passes we bypass the
initialization done at expand time, in particular prepare_function_start
which among other things does:
if (flag_stack_usage_info)
{
cfun->su = ggc_cleared_alloc<stack_usage> ();
cfun->su->static_stack_size = -1;
}
and so cfun->su is uninitialized.
Note, if I replace in the testcase __RTL (startwith ("vregs")) with just __RTL,
it ICEs exactly in prepare_function_start on the assertion that
gcc_assert (!get_last_insn ());
Note prepare_function_start initializes a bunch of other global vars:
cse_not_expected = ! optimize;
/* Caller save not needed yet. */
caller_save_needed = 0;
/* We haven't done register allocation yet. */
reg_renumber = 0;
/* Indicate that we have not instantiated virtual registers yet. */
virtuals_instantiated = 0;
/* Indicate that we want CONCATs now. */
generating_concat_p = 1;
/* Indicate we have no need of a frame pointer yet. */
frame_pointer_needed = 0;
If we don't start with expand pass, I guess we want !generating_concat_p, but
the others really depend on what exact pass it starts with. I'm afraid the RTL
passes has lots of other state that I don't really see how run_rtl_passes would
make it work. E.g. reload_completed, epilogue_completed, regstack_completed,
... All those start initially clear (or as set above), and at some point are
changed after some pass.
