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].
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 ***