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?
