[Bug target/64971] [5/6 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32

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

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

--- Comment #11 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #10)
> Ramana, do you want to give this to someone on your team to wrap up?


Kyrill, do you mind picking this up ?

(In reply to Jeffrey A. Law from comment #9)
> Seems rather hackish to start accepting non-Pmode for the address.  Though
> looking at the docs, I guess it's not strictly incorrect.
> 
> The @code{symbol_ref} contains a mode, which is usually @code{Pmode}.
> Usually that is the only mode for which a symbol is directly valid.
> 
> And the *call* pattern documentation waffles a bit too:
> 
> Operand 0 should be a @code{mem} RTX whose address is the address of the
> function.  Note, however, that this address can be a @code{symbol_ref}
> expression even if it would not be a legitimate memory address on the
> target machine.
> 
> So I won't object to the aarch64 maintainers accepting the additional mode
> (Richard's approach), nor will I object to forcing the mode in the expander
> (Andrew's approach)

Forcing the mode in the expander and guarding it with TARGET_ILP32 looks more
appealing to me right now purely because of where we are with the release cycle
though the points Richard makes need to be looked into. I'll let the aarch64
maintainers decide on which one to take.