From: Alexandre Oliva <aoliva@redhat.com>
To: "Bin.Cheng" <amker.cheng@gmail.com>
Cc: gcc-patches List <gcc-patches@gcc.gnu.org>
Subject: Re: [PR84682] disregard address constraints on non-addresses
Date: Wed, 14 Mar 2018 08:32:00 -0000 [thread overview]
Message-ID: <ortvtj2ie5.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <CAHFci29bEvU9g85o_xc7jRjU-cKxmfRu5ExQH8rbgus+D_Q4tg@mail.gmail.com> (Bin Cheng's message of "Mon, 12 Mar 2018 10:14:05 +0000")
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
next prev parent reply other threads:[~2018-03-14 8:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-09 6:45 Alexandre Oliva
2018-03-09 14:50 ` Vladimir Makarov
2018-03-09 18:51 ` Jeff Law
2018-03-12 10:14 ` Bin.Cheng
2018-03-14 8:32 ` Alexandre Oliva [this message]
2018-03-14 11:42 ` Bin.Cheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ortvtj2ie5.fsf@lxoliva.fsfla.org \
--to=aoliva@redhat.com \
--cc=amker.cheng@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).