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.