https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97822
--- Comment #26 from Werner Zeh <werner.zeh at coreboot dot org> --- (In reply to Uroš Bizjak from comment #15) > Hm, the generated code does not look right: > > _Z1hv: > pushq %rbp > .seh_pushreg %rbp > pushq %rdi > .seh_pushreg %rdi > pushq %rsi > .seh_pushreg %rsi > subq $160, %rsp > .seh_stackalloc 160 > andq $-16, %rsp > (*)-> leaq (%rsp), %rbp > .seh_setframe %rbp, 0 > movups %xmm6, 0(%rbp) > .seh_savexmm %xmm6, 0 > movups %xmm7, 16(%rbp) > .seh_savexmm %xmm7, 16 > movups %xmm8, 32(%rbp) > .seh_savexmm %xmm8, 32 > movups %xmm9, 48(%rbp) > .seh_savexmm %xmm9, 48 > movups %xmm10, 64(%rbp) > .seh_savexmm %xmm10, 64 > movups %xmm11, 80(%rbp) > .seh_savexmm %xmm11, 80 > movups %xmm12, 96(%rbp) > .seh_savexmm %xmm12, 96 > movups %xmm13, 112(%rbp) > .seh_savexmm %xmm13, 112 > movups %xmm14, 128(%rbp) > .seh_savexmm %xmm14, 128 > movups %xmm15, 144(%rbp) > .seh_savexmm %xmm15, 144 > .seh_endprologue > call _Z1fv > nop > movaps (%rsp), %xmm6 > movaps 16(%rsp), %xmm7 > movaps 32(%rsp), %xmm8 > movaps 48(%rsp), %xmm9 > movaps 64(%rsp), %xmm10 > movaps 80(%rsp), %xmm11 > movaps 96(%rsp), %xmm12 > movaps 112(%rsp), %xmm13 > movaps 128(%rsp), %xmm14 > movaps 144(%rsp), %xmm15 > (**)-> leaq 160(%rbp), %rsp > popq %rsi > popq %rdi > popq %rbp > ret > > Please note that at (*) RBP gets assigned the value of realigned RSP. At > (**) RSP gets assigned the value of RBP + 160, but RBP here holds the value > of realigned RSP. This will misaling the stack for follow-up POP > instructions. Hi Uros, the observed stack pointer alignment issues are not introduced by the proposed fix but were introduced by commit 074226d5aa86cd3de517014acfe34c7f69a2ccc7. It is even worse because the RSP restoration happens on base of RBP but RBP was aligned already earlier. This means the subsequent POP operations can only succeed if the initial RSP value was already aligned. Further on, the obvious asymmetry in the prolog (all based on RBP) and the epilog (all based on RSP) seem quite odd to me. In addition, it is strange that the XMM save operations happens unaligned [movups %xmm6, 0(%rbp)] while the RBP is already aligned. In the epilog, aligned restore happens [movaps (%rsp), %xmm6]. So I guess that my patch is not wrong but not sufficient at all. What do you think?
