https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213
--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> --- We have large-stack-frame-growth that is relative, so yes, increasing stack size of caller makes gcc to think that it is heavy and making it event heavier will not hurt that much. We originally ran into stack size growth issues after implementing logic to inline functions called once. In things like glibc printf where we ended up inlining some exotic formater (as called once) that made the stack too large for multithreaded apps. Also sometimes we inlined some heavy function that is off the hot path. While relative growth cap may not be best possible for all cases, I can't think of reasonable way doing this better. With the new code to determine basic blocks that are executed at every execution of the function I plan to relax stack size limits a bit by bypassing them when the call is known to be always allocated (and thus the stack will be always taken) This is also relatively common problem in Fortran where fortran IO (typically done somewhere in debug code) tends to crate large on-stack structures preventing inlining.
