https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104989
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:6adbb51eaa85f5bfed1ee06327daca306d48986d commit r12-7749-g6adbb51eaa85f5bfed1ee06327daca306d48986d Author: Jakub Jelinek <ja...@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 <ja...@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.
