https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121389
--- Comment #12 from GCC 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:18c32a391685256d2fbd6e3e6b2f7f93200bb912 commit r16-3077-g18c32a391685256d2fbd6e3e6b2f7f93200bb912 Author: Jakub Jelinek <ja...@redhat.com> Date: Fri Aug 8 09:20:51 2025 +0200 tailc: Handle other forms of finally_tmp.N conditional cleanups after musttail [PR121389] 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 <ja...@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.
