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 middle-end/101160] [12 Regression] ICE in df_word_lr_local_compute, at df-problems.c:2962 since r12-1702-g7232f7c4c2d72743
Date: Tue, 22 Jun 2021 13:24:05 +0000	[thread overview]
Message-ID: <bug-101160-4-UDzkOTmzwV@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-101160-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:9b613e825d706b18f69e40edaee3eaf27d28f5cb

commit r12-1727-g9b613e825d706b18f69e40edaee3eaf27d28f5cb
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Jun 22 15:21:35 2021 +0200

    expand: Fix up empty class return optimization [PR101160]

    On Mon, Jun 14, 2021 at 11:24:22PM -0400, Jason Merrill via Gcc-patches
wrote:
    > The x86_64 psABI says that an empty class isn't passed or returned in
memory or
    > registers, so we shouldn't set %eax in this function.  Is this a
reasonable
    > place to implement that?  Another possibility would be to remove the hack
to
    > prevent i386.c:function_value_64 from returning NULL in this case and fix
the
    > callers to deal, but that seems like more work.
    >
    > The df-scan hunk catches the case where we look at a 0-length reg and
build
    > a range the length of unsigned int, which happened before I changed
    > assign_parms to match expand_function_end.

    The assign_params change unfortunately breaks e.g. the following testcase.
    The problem is that some passes (e.g. subreg lowering but assign_parms
    comments also talk about delayed slot scheduling) rely on crtl->return_rtx
    not to contain pseudo registers, and the assign_parms change results
    in the pseudo in there not being replaced with a hard register.

    The following patch instead clears the crtl->return_rtx if a function
    returns TYPE_EMPTY_P structure, that way (use (pseudo)) is not emitted
    into the IL and it is treated like more like functions returning void.

    I've also changed the effective target on the empty-class1.C testcase, so
    that it doesn't fail on x86_64-linux with -m32 testing.

    2021-06-22  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/101160
            * function.c (assign_parms): For decl_result with TYPE_EMPTY_P type
            clear crtl->return_rtx instead of keeping it referencing a pseudo.

            * g++.target/i386/empty-class1.C: Require lp64 effective target
            instead of x86_64-*-*.
            * g++.target/i386/empty-class2.C: New test.

  parent reply	other threads:[~2021-06-22 13:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22  6:23 [Bug c++/101160] New: " marxin at gcc dot gnu.org
2021-06-22  6:23 ` [Bug c++/101160] " marxin at gcc dot gnu.org
2021-06-22  6:28 ` [Bug middle-end/101160] " pinskia at gcc dot gnu.org
2021-06-22  9:26 ` jakub at gcc dot gnu.org
2021-06-22  9:40 ` jakub at gcc dot gnu.org
2021-06-22 13:24 ` cvs-commit at gcc dot gnu.org [this message]
2021-07-18 10:42 ` jakub 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-101160-4-UDzkOTmzwV@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).