[Bug rtl-optimization/64882] [5 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> And the problem seems to be that the mode argument to address_no_seg_operand
> predicate is completely ignored.
> 
> The big question is where to fix this.
> I've tried changing ix86_legitimate_address_p, but that ICEs pretty much
> everywhere, on the other side doing it just in address_no_seg_operand might
> be sufficient for this exact testcase, but what about others? 
> config/i386/predicates.md has tons of predicates that check
> "address_operand" and do something on top of that.
> 
> --- gcc/recog.c.jj	2015-01-15 20:25:30.000000000 +0100
> +++ gcc/recog.c	2015-01-31 11:33:28.546090770 +0100
> @@ -1122,6 +1122,8 @@ general_operand (rtx op, machine_mode mo
>  int
>  address_operand (rtx op, machine_mode mode)
>  {
> +  if (GET_MODE (op) != mode && mode != VOIDmode && GET_MODE (op) !=
> VOIDmode)
> +    return 0;
>    return memory_address_p (mode, op);
>  }
>  
> seems to fix this testcase, can try to bootstrap/regtest that, but as it is
> a generic change, there is a risk of breaking many other ports.
> 
> So, any thoughts on this?  Or should it be postreload's duty to verify that
> modes match?

Ah, doing it in ix86_legitimate_address_p is of course wrong, since the mode
passed in that case isn't the desired mode of the address, but the mode of the
MEM containing the address.  But IMHO the mode passed to address_operand is the
mode of the address, rather than the mode of the MEM.