http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503
Summary: Incorrect stack alignment, produced by inline
assembler in tests gcc.target/i386/cleanup-1.c and
gcc.target/i386/cleanup-2.c
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.v.zolotuk...@gmail.com
CC: michael.v.zolotuk...@gmail.com
Host: x64
Target: x64
Build: 4.7.0 20110619
The tests contain asm-listing like this:
__asm (
testl %0, %0
jnz 1f
.subsection 1
.type _L_mutex_lock_%=, @function
_L_mutex_lock_%=:
1: leaq %1, %%rdi
2: subq $128, %%rsp
3: call bar
4: addq $128, %%rsp
5: jmp 21f
...
As _L_mutex_lock is a function, GCC generates a prologue and epilogue for it -
in prologue stack alignment is performed (according to ABI64, stack should be
aligned to 128-bit).
Before a call, SP is assumed to be a multiple of 16, at function entry, when
return address is pushed to stack, (SP+8) becomes multiple of 16 - GCC uses
these assumptions when generating prologue for stack alignment.
But if JUMP is used instead of CALL, 8-byte displacement doesn't take place,
and stack becomes unaligned - that's violation of ABI.
To fix this error, JUMP should be replaced with CALL, or L_mutex_lock shouldn't
be declared as a function.
