[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

[michael.v.zolotukhin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503

--- Comment #2 from Michael Zolotukhin <michael.v.zolotukhin at gmail dot com> 2011-06-22 17:50:34 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > 
> > 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).
> 
> I didn't see any prologue and epilogue for _L_mutex_lock. Do you have
> a run-time testcase to show the problem?

I don't have run-time test for this fail, but here is a way to see the problem:

Firstly, you need to compile the test (it is in gcc/testsuite/gcc.target/i386):

gcc cleanup-1.c   -fexceptions -fnon-call-exceptions
-fasynchronous-unwind-tables -O0  -lm -g -fno-inline

Then, in debugger one can see that before each callq before foo (here 'before'
means 'upper in call stack') RSP contains aligned value, after foo (deeper in
call stack) - unaligned.


Here is corresponding a assembler dump:

-Dump of assembler code for function foo:
   0x0000000000400886 <+0>:     push   %rbp
   0x0000000000400887 <+1>:     mov    %rsp,%rbp
   0x000000000040088a <+4>:     push   %r12
   0x000000000040088c <+6>:     push   %rbx
   0x000000000040088d <+7>:     sub    $0x98,%rsp         # It is the prologue,
   0x0000000000400894 <+14>:    mov    %edi,-0x114(%rbp)  # that I've spoken
   0x000000000040089a <+20>:    mov    -0x114(%rbp),%ebx  # about.
   0x00000000004008a0 <+26>:    lea    -0x110(%rbp),%r12  #
   0x00000000004008a7 <+33>:    test   %ebx,%ebx
   0x00000000004008a9 <+35>:    jne    0x400941 <_L_mutex_lock_216>
   0x00000000004008af <+41>:    add    $0x98,%rsp
   0x00000000004008b6 <+48>:    pop    %rbx
   0x00000000004008b7 <+49>:    pop    %r12
   0x00000000004008b9 <+51>:    leaveq
   0x00000000004008ba <+52>:    retq
-End of assembler dump.

RTL dumps showed that these instructions appear phase "197r.pro_and_epilogue".

I'm not sure, if prologue generation is incorrect - in my opinion the problem
is with such untrivial call of _L_mutex_lock.