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.

0 files changed, 0 insertions, 0 deletions