public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762 Date: Wed, 01 Apr 2020 08:09:01 +0000 [thread overview] Message-ID: <bug-93974-4-YTk7Yi2f1l@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-93974-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 --- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Richard Sandiford said on this PR, probably lost due to sourceware migration: Sorry for the slow reply, been a bit of a hectic week. I think both fixes would be valid. Like you say, the address parsing code isn't yet ready to handle addresses that apply an offset *before* the address "mutations". That's because no target has yet wanted to support such an address. So as things stand, the current address is not valid and shouldn't have been created. In some ways this is similar to creating an invalid highpart subreg for the upper word of a doubleword vector hard register, or a subreg that falls foul of some simplify_subreg_regno rule. The RA has code to avoid doing that, see init_subregs_of_mode and its users. We could do something similar here for REG_EQUIV MEMs. One option would be to key off whether strip_address_mutations is a no-op on the address. Another would be to check whether each required sub-MEM is valid for its mode and offset. The latter would be more elaborate but might produce better code in general, not just for cases like this. Like you say in comment 4, even the zero-offset half isn't actually a valid address for PowerPC, so either of the two options should give better code as well as fixing the bug. On the other hand, the idea was always that address_info and its users could be extended if new targets have new requirements. So if we want to make this operation valid then that would be OK too.
next parent reply other threads:[~2020-04-01 8:09 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-93974-4@http.gcc.gnu.org/bugzilla/> 2020-04-01 8:09 ` jakub at gcc dot gnu.org [this message] 2020-04-01 8:10 ` jakub at gcc dot gnu.org 2020-04-01 15:58 ` bergner at gcc dot gnu.org 2020-04-01 16:02 ` jakub at gcc dot gnu.org 2020-04-01 16:09 ` bergner at gcc dot gnu.org 2020-04-15 9:58 ` jakub at gcc dot gnu.org 2020-04-15 20:05 ` bergner at gcc dot gnu.org 2020-04-15 22:35 ` bergner at gcc dot gnu.org 2020-04-15 23:24 ` segher at gcc dot gnu.org 2020-04-17 4:27 ` cvs-commit at gcc dot gnu.org 2020-04-17 4:28 ` bergner at gcc dot gnu.org
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=bug-93974-4-YTk7Yi2f1l@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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: linkBe 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).