User account creation filtered due to spam.

Bug 11232 - stack allocation bug?
Summary: stack allocation bug?
Status: RESOLVED DUPLICATE of bug 9624
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: unknown
: P2 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-18 09:19 UTC by josh abbott
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: (see report content)
Target: " "
Build: " "
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description josh abbott 2003-06-18 09:19:29 UTC
We are inquiring about how GCC determines the stack size after noticing what appears 
to be some inconsistencies. While word size is 4 bytes, a buffer declared as 
buffer[5] would in some instances have 24 bytes allocated for it when only 8 are 
needed. In other instances with multiple buffers and a single printf() in the code, 
the stack allocation would be x times larger than it would appear to need.
Two examples that work on redhat8 and redhat7.3 distro releases, are attached.
The gcc versions we've tested on are as follows: 

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info 
--enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-
system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

and

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
 gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113

We are interested in whether or not this is the desired behavior of gcc?

joshabbott@gmx.net
and
andrewg@d2.net.au


----------------------
example1.c
----------------------
void function(void) {
  char buffer1[5];
  char buffer2[10];
 } 
 void main() {
  function();
 }

----------------------
compiled with:  gcc example1.c -o example1
----------------------
gdb example1, disassemble function:

 0x80482f4 : push   %ebp
 0x80482f5 : mov    %esp,%ebp
 0x80482f7 : sub    $0x28,%esp
 0x80482fa : leave  
 0x80482fb : ret 
 

it allocates 40 bytes when it should only use 20.


------------------------
example2.c
------------------------

void function(void) {
  char buffer1[5];
  printf("buffer1: 0x%x\n",buffer1);
 } 
 void main() {
  function();
 }

-------------------------
compiled with: gcc example2.c -o example2
-------------------------
gdb example2, disassemble function

 0x8048328 : push   %ebp
 0x8048329 : mov    %esp,%ebp
 0x804832b : sub    $0x18,%esp
 0x804832e : sub    $0x8,%esp
 0x8048331 : lea    0xffffffe8(%ebp),%eax
 0x8048334 : push   %eax
 0x8048335 : push   $0x80483bc
 0x804833a : call   0x8048268 
 0x804833f : add    $0x10,%esp
 0x8048342 : leave  
 0x8048343 : ret


in this example it takes 24 bytes for buffer1[5].
Comment 1 Wolfgang Bangerth 2003-06-18 13:43:32 UTC
This is a known problem that is recorded in a number of other reports
already, for example PR 9624. Using optimization sometimes helps but 
not always.

W.

*** This bug has been marked as a duplicate of 9624 ***