This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR84682] disregard address constraints on non-addresses


On Wed, Mar 14, 2018 at 8:03 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> 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.
Yes, the assert imposes stronger condition on input, which it could simply
return false indicating an invalid address.  I will test a change to
see if there
is any fallout.

Thanks,
bin
>
> --
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]