c/3215: gcc-2.95.3 and 2.95.4 - incorrect handling of the local stack frame

c/3215: gcc-2.95.3 and 2.95.4 - incorrect handling of the local stack frame

[prom]

>Number:         3215
>Category:       c
>Synopsis:       gcc-2.95.3 and 2.95.4 - incorrect handling of the local stack frame
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 17 20:16:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Ingo Albrecht
>Release:        gcc version 2.95.4 20010604 (Debian prerelease), gcc version 2.95.3 [FreeBSD] 20010315 (release)
>Organization:
>Environment:
Debian GNU/Linux sid/unstable on i686-pc
FreeBSD 4.3-STABLE on i686-pc
Problem is IA32-specific.
>Description:
gcc 2.95.3 and 2.95.4 seem to hae an incorrect handling of the size
of the local stack frame. allocating less than 16 bytes by local variable
declarations results in 0x18 bytes being reserved by substracting %esp,
allocating more than 16 bytes results in 0x28 bytes being reserved.
i did not check for compiler behaviour with more than 24 bytes of
variables, but it is likely that this problem persists with increasing amount
of data. gcc-3.0 (gcc version 3.0 20010613 (Debian prerelease)) and
gcc -2.96 (gcc version 2.96 20000731 (Red Hat Linux 7.0)) handle this
correctly for the tested situations, but as the bug exists in 2.95.4 prerelease
this is a current problem.
>How-To-Repeat:
just compile code like the following one-liner:

int main (void) { int foobla; }

and disassemble the result. using "objdump --disassemble-all" to do so
results in the following output:

test.o:     file format elf32-i386

Disassembly of section .text:

00000000 <main>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 ec 18                sub    $0x18,%esp
   6:   c9                      leave  
   7:   c3                      ret    
Disassembly of section .data:

The problem becomes obvious in line #3 of the disassembly of main().
While the size of the data having to fit on the local stack frame is only
4 bytes the compiler generates code that reserves 0x18 bytes. Slowly
increasing the size of the local variables in main() shows that this
behaviour does not change until the total size of the variables reaches
17 bytes. Compiling code like:

int main (void) { int a,b,c,d; char x; }

results in the same code except for the space being reserved on the
stack frame which is now 0x28, changing the look of line #3 in the
disassembly of main() slighly to:

   3:   83 ec 28                sub    $0x28,%esp
>Fix:
Not known to me. problem seems to be fixed
in "gcc version 2.96 20000731" and "gcc version 3.0 20010613".
>Release-Note:
>Audit-Trail:
>Unformatted: