https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109567
--- Comment #2 from Petr Skocik <pskocik at gmail dot com> --- (In reply to Andrew Pinski from comment #1) > Compiling with -fno-omit-frame-pointer shows what is happening really. > > It is reserving space for the frame pointer on the stack. I am not 100% sure > but I think that is required even if the frame pointer is not saved/restored. It's probably not super important that space be reserved for the would-be fp. Clang doesn't do it: https://godbolt.org/z/39cY45MbE For, e.g., void take7(long,long,long,long,long,long,long); void call7(long A,long B,long C,long D,long E,long F){ take7(A,B,C,D,E,F,0); } it produces call7: pushq %rax movq $0, (%rsp) callq take7@PLT popq %rax retq Now clang is getting clunky here with the push of 0 via the mov, which gcc does directly via push $0, but no extra stack allocation with clang. The 7th argument is passed thru the stack and simultaneously aligns the stack.
