https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127334
--- Comment #1 from JingYao Zhang <220245569 at seu dot edu.cn> --- Gentle ping on this issue (and thank you @rguenth for triaging to the x86 target component). Adding a bit of extra context on the two possible fix locations in case it is helpful: 1. **In `gcc/config/i386/i386-options.cc` (matching `-mstack-arg-probe`)**: `i386-options.cc` already forces `ACCUMULATE_OUTGOING_ARGS` when `TARGET_STACK_PROBE` (`-mstack-arg-probe`) is enabled, because the outgoing-argument push path does not probe large per-call stack adjustments. Adding `flag_stack_clash_protection` to that condition (or to `ACCUMULATE_OUTGOING_ARGS` in `i386.h`) routes large outgoing aggregate arguments through the prologue allocation, where `ix86_adjust_stack_and_probe_stack_clash` already probes every guard interval. 2. **In `gcc/expr.cc` (`push_block`)**: Alternatively, when `!ACCUMULATE_OUTGOING_ARGS`, `push_block()` currently calls `anti_adjust_stack (size)` directly; calling `anti_adjust_stack_and_probe_stack_clash (size)` when `flag_stack_clash_protection` is enabled would probe large per-call outgoing argument allocations in a target-independent way. Please let us know which direction maintainers prefer -- we would be glad to test and submit a patch.
