public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-7749] calls: Fix error recovery after sorry differently [PR104989] Date: Tue, 22 Mar 2022 07:40:16 +0000 (GMT) [thread overview] Message-ID: <20220322074016.A04ED3857823@sourceware.org> (raw) https://gcc.gnu.org/g:6adbb51eaa85f5bfed1ee06327daca306d48986d commit r12-7749-g6adbb51eaa85f5bfed1ee06327daca306d48986d Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Mar 22 08:39:40 2022 +0100 calls: Fix error recovery after sorry differently [PR104989] On Mon, Feb 28, 2022 at 07:52:56AM -0000, Roger Sayle wrote: > This patch resolves PR c++/84964 which is an ICE in the middle-end after > emitting a "sorry, unimplemented" message, and is a regression from > earlier releases of GCC. This issue is that after encountering a > function call requiring an unreasonable amount of stack space, the > code continues and falls foul of an assert checking that stack pointer > has been correctly updated. The fix is to (locally) consider aborted > function calls as "no return", which skips this downstream sanity check. As can be seen on PR104989, just setting ECF_NORETURN after sorry is quite risky and leads to other ICEs. The problem is that ECF_NORETURN calls better should be at the end of basic blocks that don't have any fallthru successor edges, otherwise we can ICE later. This patch instead sets sibcall_failure if in pass == 0 (sibcall_failure means that the tail call sequence is not useful/not desirable and throws it away) and otherwise sets a new bool variable that will let us pass the assertion and also throws away the whole call sequence, I think that is best for error recovery. 2022-03-22 Jakub Jelinek <jakub@redhat.com> PR rtl-optimization/104989 * calls.cc (expand_call): Don't set ECF_NORETURN in flags after sorry for passing too large argument, instead set sibcall_failure for pass == 0, or a new normal_failure flag otherwise. If normal_failure is set, don't assert all stack has been deallocated at the end and throw away the whole insn sequence. * g++.dg/other/pr104989.C: New test. Diff: --- gcc/calls.cc | 9 ++++++++- gcc/testsuite/g++.dg/other/pr104989.C | 9 +++++++++ 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/gcc/calls.cc b/gcc/calls.cc index 50fa7b8e350..e13469cfd43 100644 --- a/gcc/calls.cc +++ b/gcc/calls.cc @@ -3068,6 +3068,7 @@ expand_call (tree exp, rtx target, int ignore) for (pass = try_tail_call ? 0 : 1; pass < 2; pass++) { int sibcall_failure = 0; + bool normal_failure = false; /* We want to emit any pending stack adjustments before the tail recursion "call". That way we know any adjustment after the tail recursion call can be ignored if we indeed use the tail @@ -3448,7 +3449,10 @@ expand_call (tree exp, rtx target, int ignore) { sorry ("passing too large argument on stack"); /* Don't worry about stack clean-up. */ - flags |= ECF_NORETURN; + if (pass == 0) + sibcall_failure = 1; + else + normal_failure = true; continue; } @@ -3905,9 +3909,12 @@ expand_call (tree exp, rtx target, int ignore) /* Verify that we've deallocated all the stack we used. */ gcc_assert ((flags & ECF_NORETURN) + || normal_failure || known_eq (old_stack_allocated, stack_pointer_delta - pending_stack_adjust)); + if (normal_failure) + normal_call_insns = NULL; } /* If something prevents making this a sibling call, diff --git a/gcc/testsuite/g++.dg/other/pr104989.C b/gcc/testsuite/g++.dg/other/pr104989.C new file mode 100644 index 00000000000..8b1f79b5f9b --- /dev/null +++ b/gcc/testsuite/g++.dg/other/pr104989.C @@ -0,0 +1,9 @@ +// PR rtl-optimization/104989 +// { dg-do compile } +// { dg-options "-fnon-call-exceptions" } + +struct a { + short b : -1ULL; +}; +void c(...) { c(a()); } +// { dg-excess-errors "" }
reply other threads:[~2022-03-22 7:40 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220322074016.A04ED3857823@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@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).