User account creation filtered due to spam.

Bug 10415 - allocated stack space non optimimal
Summary: allocated stack space non optimimal
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2003-04-15 18:06 UTC by b.grzes
Modified: 2003-07-25 17:33 UTC (History)
2 users (show)

See Also:
Host:
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 Wolfgang Bangerth 2003-04-15 15:12:46 UTC
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: middle-end/10415: allocated stack space non optimimal
Date: Tue, 15 Apr 2003 15:12:46 -0500 (CDT)

 ---------- Forwarded message ----------
 Date: Tue, 15 Apr 2003 21:59:33 +0200
 From: GrzegorzB <b.grzes@interia.pl>
 To: bangerth@dealii.org
 Subject: Re: middle-end/10415: allocated stack space non optimimal
 
 bangerth@dealii.org wrote:
 > Old Synopsis: problem with stack
 > New Synopsis: allocated stack space non optimimal
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: bangerth
 > State-Changed-When: Tue Apr 15 18:27:24 2003
 > State-Changed-Why:
 >     Somehow the attachment got corrupted. Can you send the 
 >     program you used again?
 >     
 >     Thanks
 >       Wolfgang
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10415
 > 
 
 Program test.c:
 
 void f()
 {
 	char buf[3];
 }
 
 main()
 {
 	f();
 }
 
 I compile this:
 gcc -S -o test test.c
 
 In test is:
         .file   "test.c"
          .text
          .align 2
 .globl f
          .type   f,@function
 f:
          pushl   %ebp
          movl    %esp, %ebp
          subl    $24, %esp    <-- I thing its wrong
          leave
          ret
 .Lfe1:
          .size   f,.Lfe1-f
          .align 2
 .globl main
          .type   main,@function
 main:
          pushl   %ebp
          movl    %esp, %ebp
          subl    $8, %esp
          andl    $-16, %esp
          movl    $0, %eax
          subl    %eax, %esp
          call    f
          leave
          ret
 .Lfe2:
          .size   main,.Lfe2-main
          .ident  "GCC: (GNU) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)"
 
 Sorry, I didn't explain that well.
 Grzegorz Bieda
 
 
 ----------------------------------------------------------------------
 KLIKNIJ 2 razy TAK >>> http://link.interia.pl/f170d
 
 

Comment 1 Wolfgang Bangerth 2003-04-15 15:15:25 UTC
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: GrzegorzB <b.grzes@interia.pl>
Cc: gcc-gnats@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>
Subject: Re: middle-end/10415: allocated stack space non optimimal
Date: Tue, 15 Apr 2003 15:15:25 -0500 (CDT)

 > Program test.c:
 > 
 > void f() {
 > 	char buf[3];
 > }
 > 
 > main() {
 > 	f();
 > }
 > 
 > I compile this:
 > gcc -S -o test test.c
 
 What happens if you switch on optimization? Is stack allocation better 
 then?
 
 [I think that the compiler will just optimize away everything in that 
 case, but you might prevent this by doing something like
 
 void p(char *x);
 void f() {
   char buf[3];
   p(buf);
 }
 
 and simply not defining f().]
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 

Comment 2 Wolfgang Bangerth 2003-04-15 17:35:03 UTC
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: middle-end/10415: allocated stack space non optimimal
Date: Tue, 15 Apr 2003 17:35:03 -0500 (CDT)

 ---------- Forwarded message ----------
 Date: Tue, 15 Apr 2003 22:42:42 +0200
 From: GrzegorzB <b.grzes@interia.pl>
 To: Wolfgang Bangerth <bangerth@ices.utexas.edu>
 Subject: Re: middle-end/10415: allocated stack space non optimimal
 
 Wolfgang Bangerth wrote:
 >>Program test.c:
 >>
 >>void f() {
 >>	char buf[3];
 >>}
 >>
 >>main() {
 >>	f();
 >>}
 >>
 >>I compile this:
 >>gcc -S -o test test.c
 > 
 > 
 > What happens if you switch on optimization? Is stack allocation better 
 > then?
 > 
 > [I think that the compiler will just optimize away everything in that 
 > case, but you might prevent this by doing something like
 > 
 > void p(char *x);
 > void f() {
 >   char buf[3];
 >   p(buf);
 > }
 > 
 > and simply not defining f().]
 > 
 > W.
 > 
 If I compile test.c with option -O0, I have (for "char buf[3]"):
 
   pushl   %ebp
          movl    %esp, %ebp
          subl    $24, %esp
          leave
 
 for option -O3 is:
 
 pushl   %ebp
          movl    %esp, %ebp
          subl    $24, %esp
          andl    $-16, %esp
          leave
 If is "char buff[4]" and -O3 is:
 
 pushl   %ebp
          movl    %esp, %ebp
          subl    $8, %esp
          andl    $-16, %esp
          leave
 
 and for -O0 option (and "char buf[4]"):
 
 pushl   %ebp
          movl    %esp, %ebp
          subl    $4, %esp
          leave
 
 So sorry, I thought it is a bug.
 
 
 
 
 ----------------------------------------------------------------------
 KLIKNIJ 2 razy TAK >>> http://link.interia.pl/f170d
 
 

Comment 3 Wolfgang Bangerth 2003-04-15 17:43:12 UTC
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: GrzegorzB <b.grzes@interia.pl>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: middle-end/10415: allocated stack space non optimimal
Date: Tue, 15 Apr 2003 17:43:12 -0500 (CDT)

 > So sorry, I thought it is a bug.
 
 Well, I still think that this is a quality of implementation bug, gcc 
 should be able to do better. I mean, it is not _wrong_ if the compiler 
 allocated too much stack space, it is just wasteful.
 
 There are a number of reports in the bug database about this problem, 
 which also have some documentation about what is the cause for this inside 
 the compiler. Let me close this report, since there are others.
 
 Thanks anyway
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 
Comment 4 b.grzes 2003-04-15 18:06:01 UTC
char buf[1], char buf[2], char buf[4] allocate on the stack 4 bytes:
pushl   %ebp
        movl    %esp, %ebp
        subl    $4, %esp

char buf[3], char buf[5], ... char buf[7] allocate 24 bytes
pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp

char buf[8] alloocate 8 bytes:
pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp

I compile program with option -S.

Release:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs

Environment:
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)
Comment 5 Wolfgang Bangerth 2003-04-15 18:27:24 UTC
State-Changed-From-To: open->feedback
State-Changed-Why: Somehow the attachment got corrupted. Can you send the 
    program you used again?
    
    Thanks
      Wolfgang
Comment 6 Wolfgang Bangerth 2003-04-15 22:56:17 UTC
State-Changed-From-To: feedback->closed
State-Changed-Why: Closed in favor of duplicates with more information.