[PR84682] disregard address constraints on non-addresses

Alexandre Oliva aoliva@redhat.com
Wed Mar 14 08:32:00 GMT 2018


On Mar 12, 2018, "Bin.Cheng" <amker.cheng@gmail.com> wrote:

> internal compiler error: in aarch64_classify_address, at
> config/aarch64/aarch64.c:5678
> 0xfe3c29 aarch64_classify_address
>     /.../build/src/gcc/gcc/config/aarch64/aarch64.c:5677
> 0xfe8be8 aarch64_legitimate_address_hook_p
>     /.../build/src/gcc/gcc/config/aarch64/aarch64.c:5958
> 0xc0149e default_addr_space_legitimate_address_p(machine_mode,
> rtx_def*, bool, unsigned char)
>     /.../build/src/gcc/gcc/targhooks.c:1476
> 0xb5b9f1 memory_address_addr_space_p(machine_mode, rtx_def*, unsigned char)
>     /.../build/src/gcc/gcc/recog.c:1334
> 0xb5d278 address_operand(rtx_def*, machine_mode)
>     /.../build/src/gcc/gcc/recog.c:1073
> 0xb5e186 asm_operand_ok(rtx_def*, char const*, char const**)
>     /.../build/src/gcc/gcc/recog.c:1816
> 0x73f440 expand_asm_stmt
>     /.../build/src/gcc/gcc/cfgexpand.c:3138
> 0x742d3c expand_gimple_stmt_1
>     /.../build/src/gcc/gcc/cfgexpand.c:3621

> Not sure if it reveals latent bug or just inconsistent issue with
> backend though.

Possibly both, in a way.  This triggers at expand, which is much earlier
than the patch affects compilation; that call to address_operand was
already there before.  So the ICE was latent, but only in the sense that
we didn't have tests that would have triggered it.  Any asm stmt with a
p constraint and a non-address operand (with another constraint to
accept it) would have exercised this aarch64-specific ICE, and it would
do so before hitting the machine-independent ICE that the patch fixed.

aarch64_classify_address should probably return false instead of failing
that assertion.  When it comes to asm operands, there's no guarantee
that you'll get something that even looks like an address, when you're
part of the very code that's supposed to tell the rest of the compiler
what a legitimate address should look like.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer



More information about the Gcc-patches mailing list