public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/115281] [14/15 Regression] aarch64 ICE in go_through_subreg after r14-5129
Date: Thu, 30 May 2024 15:19:08 +0000	[thread overview]
Message-ID: <bug-115281-4-HzcRRcNwZJ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-115281-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115281

--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:46d931b3dd31cbba7c3355ada63f155aa24a4e2b

commit r15-929-g46d931b3dd31cbba7c3355ada63f155aa24a4e2b
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Thu May 30 16:17:58 2024 +0100

    ira: Fix go_through_subreg offset calculation [PR115281]

    go_through_subreg used:

      else if (!can_div_trunc_p (SUBREG_BYTE (x),
                                 REGMODE_NATURAL_SIZE (GET_MODE (x)), offset))

    to calculate the register offset for a pseudo subreg x.  In the blessed
    days before poly-int, this was:

        *offset = (SUBREG_BYTE (x) / REGMODE_NATURAL_SIZE (GET_MODE (x)));

    But I think this is testing the wrong natural size.  If we exclude
    paradoxical subregs (which will get an offset of zero regardless),
    it's the inner register that is being split, so it should be the
    inner register's natural size that we use.

    This matters in the testcase because we have an SFmode lowpart
    subreg into the last of three variable-sized vectors.  The
    SUBREG_BYTE is therefore equal to the size of two variable-sized
    vectors.  Dividing by the vector size gives a register offset of 2,
    as expected, but dividing by the size of a scalar FPR would give
    a variable offset.

    I think something similar could happen for fixed-size targets if
    REGMODE_NATURAL_SIZE is different for vectors and integers (say),
    although that case would trade an ICE for an incorrect offset.

    gcc/
            PR rtl-optimization/115281
            * ira-conflicts.cc (go_through_subreg): Use the natural size of
            the inner mode rather than the outer mode.

    gcc/testsuite/
            PR rtl-optimization/115281
            * gfortran.dg/pr115281.f90: New test.

  parent reply	other threads:[~2024-05-30 15:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-29 16:44 [Bug rtl-optimization/115281] New: " rsandifo at gcc dot gnu.org
2024-05-29 16:46 ` [Bug rtl-optimization/115281] " rsandifo at gcc dot gnu.org
2024-05-30 15:19 ` cvs-commit at gcc dot gnu.org [this message]
2024-05-30 15:22 ` [Bug rtl-optimization/115281] [14 " rsandifo at gcc dot gnu.org
2024-06-11  8:59 ` cvs-commit at gcc dot gnu.org
2024-06-11  8:59 ` rsandifo 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-115281-4-HzcRRcNwZJ@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: 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).