On Thu, Mar 22, 2018 at 11:07 AM, Bin.Cheng <amker.ch...@gmail.com> wrote: > On Sat, Mar 17, 2018 at 8:54 AM, Richard Sandiford > <richard.sandif...@linaro.org> wrote: >> Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> writes: >>> Hi Bin, >>> >>> On 16/03/18 11:42, Bin Cheng wrote: >>>> Hi, >>>> This simple patch fixes test case failure for pr84682-2.c by returning >>>> false on wrong mode rtx in aarch64_classify_address, rather than assert. >>>> >>>> Bootstrap and test on aarch64. Is it OK? >>>> >>>> Thanks, >>>> bin >>>> >>>> 2018-03-16 Bin Cheng <bin.ch...@arm.com> >>>> >>>> * config/aarch64/aarch64.c (aarch64_classify_address): Return false >>>> on wrong mode rtx, rather than assert. >>> >>> This looks ok to me in light of >>> https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00633.html >>> This function is used to validate inline asm operands too, not just >>> internally-generated addresses. >>> Therefore all kinds of garbage must be rejected gracefully rather than >>> ICEing. >>> >>> You'll need an approval from an AArch64 maintainer though. >> >> IMO we should make address_operand itself check something like: >> >> (GET_MODE (x) == VOIDmode || SCALAR_INT_MODE_P (GET_MODE (x))) >> >> Target-independent code fundamentally assumes that an address will not >> be a float, so I think the check should be in target-independent code >> rather than copied to each individual backend. >> >> This was only caught on aarch64 because we added the assert, but I think >> some backends ignore the mode of the address and so would actually accept >> simple float rtxes. > Hi Richard, > Thanks for the suggestion generalizing the fix. Here is the updated patch. > Bootstrap and test on x86_64 and AArch64, is it OK?
Ping. Better to have this ICE fix in GCC8? But I guess RTL review/approval is needed. Thanks, bin > > Thanks, > bin > > 2018-03-22 Bin Cheng <bin.ch...@arm.com> > > * recog.c (address_operand): Return false on wrong mode for address. > * config/aarch64/aarch64.c (aarch64_classify_address): Remove assert > since it's checked in general code now. > >> >> Thanks, >> Richard
