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.
next prev 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: 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).