[Bug target/85173] ICE in in extract_insn, at recog.c:2304 for -fstack-clash-protection on ARM

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85173

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ktkachov from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > I wonder if we shouldn't do:
> > --- gcc/explow.c	2018-01-03 21:21:39.012907765 +0100
> > +++ gcc/explow.c	2018-04-04 08:58:04.716738887 +0200
> > @@ -1625,6 +1625,7 @@ set_stack_check_libfunc (const char *lib
> >  void
> >  emit_stack_probe (rtx address)
> >  {
> > +  address = memory_address (word_mode, address);
> >    if (targetm.have_probe_stack_address ())
> >      emit_insn (targetm.gen_probe_stack_address (address));
> >    else
> > 
> > because it is tedious to do that in every emit_stack_probe caller.  Wonder
> > why all the other target happen to work even without something like that
> > (ok, some targets allow signed 32-bit offsets and maybe we never generate
> > larger offsets).
> 
> That's similar to what I've been testing. My patch uses validize_mem on the
> MEM rtx before passing it down to the target.
> I'll be posting it to gcc-patches later today

That won't fix targets that have probe_stack_address expander, which is rs6000,
powerpcspe and ia64.  Looking at those, the first two use address_operand
predicate and the last one register_operand, perhaps we need to use
create_address_operand and maybe_legitimize_operand for that case?
Perhaps instead of validize_mem we should use create_input_operand and
maybe_legitimize_operand for the gen_stack_probe case too and just use
validize_mem for the emit_move_insn case?