tailc: Handle other forms of finally_tmp.N conditional cleanups after musttail [PR121389]HEADtrunkmaster

My earlier r16-1886 PR120608 change incorrectly assumed that the
finally_tmp.N vars introduced by eh pass will be only initialized
to values 0 and 1 and there will be only EQ_EXPR/NE_EXPR comparisons
of those.

The following testcases show that is a bad assumption, the eh pass
sets finally_tmp.N vars to 0 up to some highest index depending on
hoiw many different exits there are from the finally region.
And it emits then switch (finally_tmp.N) statement for all the
different cases.  So, if it uses more than 0/1 indexes, the lowering
of the switch can turn it into a series of GIMPLE_CONDs,
  if (finally_tmp.N_M > 15)
    goto ...
  else
    goto ...

  if (finally_tmp.N_M > 7)
    goto ...
  else
    goto ...
etc. (and that also means no longer single uses).  And if unlucky,
we can see a non-lowered GIMPLE_SWITCH as well.

So, the following patch removes the assumption that it has to be 0/1
and EQ_EXPR/NE_EXPR, allows all the normal integral comparisons
and handles GIMPLE_SWITCH too.

2025-08-08  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/121389
	* tree-tailcall.cc (find_tail_calls): For finally_tmp.N
	handle not just GIMPLE_CONDs with EQ_EXPR/NE_EXPR and only
	values 0 and 1, but arbitrary non-negative values, arbitrary
	comparisons in conditions and also GIMPLE_SWITCH next to
	GIMPLE_CONDs.

	* c-c++-common/asan/pr121389-1.c: New test.
	* c-c++-common/asan/pr121389-2.c: New test.
	* c-c++-common/asan/pr121389-3.c: New test.
	* c-c++-common/asan/pr121389-4.c: New test.

0 files changed, 0 insertions, 0 deletions