https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124651
--- Comment #16 from Heiko Eißfeldt <heiko at hexco dot de> ---
I ran some statistics. You are right, normally maximum work list length is 3,
except for the extreme code like from the PR, where it went up to 157.
So I presized the list to 3 entries.
For
FOR_EACH_EDGE (e, ei, bb->succs)
if (bitmap_set_bit (m_visited, e->dest->index))
worklist.safe_push (e->dest);
I assume you meant s/bitmap_set_bit/bitmap_bit_p/, so not to change the bitmap
here.
Regarding replacing m_visited with visited from basic_block, I don't oversee
how initialization would be done without iterating over all basic blocks first.
With the current flow we have a short-circuit once the result is fixed. So we
load new successors on demand only.
I have sent a patch to the patches mailing list
[https://gcc.gnu.org/pipermail/gcc-patches/2026-April/712419.html]. This fixes
the ICE in that place.
With active checking in GCC there is another place where recursion exceeds
available stack space, see new PR124805.
