public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Klaus Espenlaub <espenlaub@informatik.uni-ulm.de> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: optimization/5477: gcc 3.0.x reserves a large stack frame, but uses only some parts of it Date: Mon, 17 Mar 2003 10:36:00 -0000 [thread overview] Message-ID: <20030317103601.4366.qmail@sources.redhat.com> (raw) The following reply was made to PR optimization/5477; it has been noted by GNATS. From: Klaus Espenlaub <espenlaub@informatik.uni-ulm.de> To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: optimization/5477: gcc 3.0.x reserves a large stack frame, but uses only some parts of it Date: Mon, 17 Mar 2003 11:33:57 +0100 bangerth@dealii.org wrote: > Synopsis: gcc 3.0.x reserves a large stack frame, but uses only some parts of it > > State-Changed-From-To: open->feedback > State-Changed-By: bangerth > State-Changed-When: Sat Mar 15 04:38:32 2003 > State-Changed-Why: > Klaus, for unknown reasons the attachment I find in the > report doesn't have a main() function -- thus no checking > possible. Do you still have the program so that you can > send it to me? I'll attach it to the report then. The code is taken from a libc subset, therefore there is no main(). If you insist on having a piece of code that can be compiled to an executable program, just append the following few lines to the code: -------------------------- snip int __console_putchar(int c) { return putchar(c); } int main(void) { do_printf(NULL, 30, "Hello, world!\n", NULL); return 0; } -------------------------- snip It doesn't make much sense in this context to have a fully compilable piece of code, since the problem is not that the resulting program fails to compile or fails to run, but that it uses one order of magniture more stack space than it would need to. So it's no good candidate for automated regression checking, since neither the compiler fails nor the compiled program. There's not much more possible than manually follow the How-To-Repeat section of the bug report. Another comment on the base problem: the compiler bug seems to be fixed in gcc-3.2. There might still be room for improvement, but the current stack consumption is quite acceptable: gcc-3.0 reserved 380 bytes of stack space, while gcc-3.2 reserves only 28. > Regarding the problem itself: yes, known problem. We > have several such reports in the database :-( The solution for me will be to upgrade to gcc-3.2 everywhere in the very near future. Regards -- Klaus Espenlaub Email: espenlaub@informatik.uni-ulm.de
next reply other threads:[~2003-03-17 10:36 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-03-17 10:36 Klaus Espenlaub [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-03-17 23:56 Wolfgang Bangerth 2003-03-15 4:38 bangerth 2002-01-24 1:06 espenlaub
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030317103601.4366.qmail@sources.redhat.com \ --to=espenlaub@informatik.uni-ulm.de \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).