Extra 8 bytes on stack in gcc 4.3 (64-bit)

Extra 8 bytes on stack in gcc 4.3 (64-bit)

[Bob Plantz]

When I use gcc -S in an x86-64 environment running in 64-bit mode on the
following C function:

int main( void )
{
        long    sum = foo( 3, 4, 5, 6, 7 );
}

gcc-4.1 allocates 16 bytes on the stack for the local variable, sum (my
comments added):

main:
.LFB3:
        pushq %rbp        # save caller base pointer
.LCFI2:
        movq %rsp, %rbp   # establish our base pointer
.LCFI3:
        subq $16, %rsp    # space for local variable
.LCFI4:
        movl $7, %r8d     # pass 5th argument
       .........

The ABI specifies that the stack pointer will be "16-byte aligned at
process entry." So even though sum only takes 8 bytes (longs in 64-bit
mode are 8 bytes), I assume that the compiler allocates 16 bytes to
maintain the 16-byte alignment. 


But with gcc-4.3 I get 24 bytes:
main:
.LFB3:
       pushq %rbp        # save caller base pointer
.LCFI2:
       movq %rsp, %rbp   # establish our base pointer
.LCFI3:
       subq $24, %rsp    # space for local variable
.LCFI4:
       movl $7, %r8d     # pass 5th argument
       .........

Now the stack is no longer 16-byte aligned. Furthermore, this stack
alignment could have been accomplished by allocating only the 8 bytes
needed for the local variable, sum.

What am I missing here?

--Bob

RE: Extra 8 bytes on stack in gcc 4.3 (64-bit)

[John (Eljay) Love-Jensen]

Hi Bob,

> Now the stack is no longer 16-byte aligned.

Leaf functions do not need to maintain stack alignment.

> Furthermore, this stack alignment could have been accomplished by allocating only the 8 bytes needed for the local variable, sum.

Optimized code, or non-optimized?

If it is non-optimized (-O0, which is the default if not specified), non-optimized code may be non-optimal.

HTH,
--Eljay

RE: Extra 8 bytes on stack in gcc 4.3 (64-bit)

[Bob Plantz]

On Fri, 2009-04-10 at 03:16 -0700, John (Eljay) Love-Jensen wrote:
> Hi Bob,
> 
> > Now the stack is no longer 16-byte aligned.
> 
> Leaf functions do not need to maintain stack alignment.
> 

main is not a leaf function here. It calls foo.

> > Furthermore, this stack alignment could have been accomplished by allocating only the 8 bytes needed for the local variable, sum.
> 
> Optimized code, or non-optimized?
> 
> If it is non-optimized (-O0, which is the default if not specified), non-optimized code may be non-optimal.
> 

It was non-optimized. But I still expected the compiler not to allocate
16 bytes on the local stack frame for no reason. Oddly (to me)

int main( void )
{
   long sum = foo( 3, 4, 5, 6, 7 );
   return 0;
}
produces:
main:
	pushq	%rbp
	movq	%rsp, %rbp
	subq	$16, %rsp



int main( void )
{
   long sum = foo( 3, 4, 5, 6, 7 );
}
produces:
main:
	pushq	%rbp
	movq	%rsp, %rbp
	subq	$24, %rsp

and
void main( void )
{
   long sum = foo( 3, 4, 5, 6, 7 );
}
produces:
main:
	pushq	%rbp
	movq	%rsp, %rbp
	subq	$16, %rsp

My "application" here is an x86-64 textbook I have written. The point of
my book is to show how the machine works at the instruction set level
when code is written at the C/C++ level. So I start my examples with C/C
++ code. The book serves as an introduction to architecture. It's not an
assembly language book, nor a compiler book. But I would like to be able
to explain things in the book that the student might see when he/she
replicates my examples. I do have a "your mileage may vary" due to
different gcc/as versions.

Bob

Re: Extra 8 bytes on stack in gcc 4.3 (64-bit)

[Ian Lance Taylor]

Bob Plantz <plantz@cds1.net> writes:

> It was non-optimized. But I still expected the compiler not to allocate
> 16 bytes on the local stack frame for no reason.

You unfortunately can not make any such assumptions about the
unoptimized compiler.

Ian