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/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327
Date: Mon, 06 Apr 2020 18:00:29 +0000	[thread overview]
Message-ID: <bug-92989-4-eHZwR97jSn@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-92989-4@http.gcc.gnu.org/bugzilla/>

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

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

https://gcc.gnu.org/g:e83714f65d1f75fc5af39f9fdc520a909dfc7635

commit r10-7570-ge83714f65d1f75fc5af39f9fdc520a909dfc7635
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Sat Apr 4 17:23:40 2020 +0100

    lra: Stop eh_return data regs being incorrectly marked live [PR92989]

    lra_assign has an assert to make sure that no pseudo is allocated
    to a conflicting hard register.  It used to be restricted to
    !flag_ipa_ra, but in g:a1e6ee38e708ef2bdef4 I'd enabled it for
    flag_ipa_ra too.  It then tripped a few times while building
    libstdc++ for mips-mti-linux.

    Previous patches fixed one of the problems: registers clobbered
    by the taking of an exception were being treated as live at the
    beginning of the EH receiver, and this got propagated to predecessor
    blocks.  But it turns out that there was a second problem: eh_return
    data registers were also being marked live in the same way.

    These registers are defined by the unwinder and so in reality they
    are live on entry to the EH receiver.  But definitions can only happen
    in blocks, not on edges, so for liveness purposes we use artificial
    definitions at the start of the EH receiver.  process_bb_lives should
    therefore model the effect of a definition, not a plain use.

    2020-04-06  Richard Sandiford  <richard.sandiford@arm.com>

    gcc/
            PR rtl-optimization/92989
            * lra-lives.c (process_bb_lives): Do not treat eh_return data
            registers as being live at the beginning of the EH receiver.

  parent reply	other threads:[~2020-04-06 18:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-92989-4@http.gcc.gnu.org/bugzilla/>
2020-04-01  8:04 ` rguenth at gcc dot gnu.org
2020-04-02 13:47 ` jakub at gcc dot gnu.org
2020-04-03 16:00 ` rsandifo at gcc dot gnu.org
2020-04-03 16:01 ` rsandifo at gcc dot gnu.org
2020-04-05  7:46 ` rsandifo at gcc dot gnu.org
2020-04-06 18:00 ` cvs-commit at gcc dot gnu.org [this message]
2020-04-06 18:02 ` 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-92989-4-eHZwR97jSn@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).