public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/104400] New: [12 Regression] v850e lra/reload failure after recent change
Date: Sat, 05 Feb 2022 18:57:50 +0000	[thread overview]
Message-ID: <bug-104400-4@http.gcc.gnu.org/bugzilla/> (raw)

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

            Bug ID: 104400
           Summary: [12 Regression] v850e lra/reload failure after recent
                    change
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: law at gcc dot gnu.org
  Target Milestone: ---

After this change:

commit 85419ac59724b7ce710ebb4acf03dbd747edeea3 (HEAD, refs/bisect/bad)
Author: Vladimir N. Makarov <vmakarov@redhat.com>
Date:   Fri Jan 21 13:34:32 2022 -0500

    [PR103676] LRA: Calculate and exclude some start hard registers for reload
pseudos

    LRA and old reload pass uses only one register class for reload pseudos
even if
    operand constraints contain more one register class.  Let us consider
    constraint 'lh' for thumb arm which means low and high thumb registers.
    Reload pseudo for such constraint will have general reg class (union of
    low and high reg classes).  Assigning the last low register to the reload
    pseudo is wrong if the pseudo is of DImode as it requires two hard regs.
    But it is considered OK if we use general reg class.  The following patch
    solves this problem for LRA.

    gcc/ChangeLog:

            PR target/103676
[ ... ]

The v850e-elf port will no longer build newlib due to a spill failure.

I've narrowed the test down, but haven't done any debugging to see if this is
really an LRA issue or a backend issue.

Compile with -O2 -mv850e3v5 to trigger:
./cc1 -O2 -mv850e3v5 j.c
 frob
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> {heap 1200k} <visibility> {heap 1200k} <build_ssa_passes>
{heap 1200k} <opt_local_passes> {heap 1200k} <remove_symbols> {heap 1616k}
<targetclone> {heap 1616k} <free-fnsummary> {heap 1616k} <emutls> {heap
1616k}Streaming LTO
 <whole-program> {heap 1616k} <profile_estimate> {heap 1616k} <icf> {heap
1616k} <devirt> {heap 1616k} <cp> {heap 1616k} <sra> {heap 1616k} <fnsummary>
{heap 1616k} <inline> {heap 1616k} <pure-const> {heap 1616k} <modref> {heap
1616k} <free-fnsummary> {heap 1616k} <static-var> {heap 1616k} <single-use>
{heap 1616k} <comdats> {heap 1616k}Assembling functions:
 frob
j.c: In function 'frob':
j.c:7:1: error: unable to find a register to spill
    7 | }
      | ^
j.c:7:1: error: this is the insn:
(insn 22 26 25 2 (set (mem/c:DI (reg/f:SI 34 .fp) [1 %sfp+-8 S8 A32])
        (reg:DI 52)) "j.c":4:7 1 {*movdi_internal}
     (expr_list:REG_DEAD (reg:DI 52)
        (nil)))
during RTL pass: reload
j.c:7:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1837


double frob (double r)
{
    r = -r;
    return r;

}

             reply	other threads:[~2022-02-05 18:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-05 18:57 law at gcc dot gnu.org [this message]
2022-02-07  7:51 ` [Bug rtl-optimization/104400] " rguenth at gcc dot gnu.org
2022-02-09 14:47 ` vmakarov at gcc dot gnu.org
2022-02-09 17:14 ` law at gcc dot gnu.org
2022-02-10 15:22 ` vmakarov at gcc dot gnu.org
2022-02-11 15:50 ` cvs-commit at gcc dot gnu.org
2022-02-11 16:57 ` law 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-104400-4@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).