public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization Date: Mon, 06 Jan 2003 22:46:00 -0000 [thread overview] Message-ID: <20030106224602.16913.qmail@sources.redhat.com> (raw) The following reply was made to PR middle-end/3973; it has been noted by GNATS. From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org> Subject: Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization Date: Mon, 6 Jan 2003 16:36:41 -0600 (CST) On Fri, 27 Dec 2002, Gerald Pfeifer wrote: > On Wed, 11 Dec 2002 bangerth@dealii.org wrote: > > Gerald, I hate to step on your toes, but I guess there is > > not much that can be done about this report -- newer gccs > > do more optimization, and they need more memory and compile > > time. Do you agree that there are probably better testcases > > for this kind of problem in the database? > > Well. This testcase would have been "self contained" (in that GCC > itself is the testcase) and it *is* a clear regression, Only true, but it's not exactly obvious where exactly the problem is. It's not in the form of a single preprocessed file that would make it so much easier to debug the problem. > but given the current trend, what can we realistically do about it? > > (I find it a bit disturbing that several old PRs of mine which > describe clear performance regressions are getting closed these > days without any form of resolution, but let's assume there are > other, better(?) PRs for this problem in our database.) I would not even pretend I would disagree with you on the matter of compile time and memory consumption, but every time I brought this up (even with numbers from our own project), nothing really happens. I fear that if we leave such general reports open, they will be open forever as nobody ventures to look at them. I personally am happy to leave it open, but since I know nothing about gcc's internals, I also can't help in fixing it :-( So what should we do? Regards Wolfgang PS: Which are those other reports you mention? ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth/
next reply other threads:[~2003-01-06 22:46 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-01-06 22:46 Wolfgang Bangerth [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-01-07 0:16 Wolfgang Bangerth 2003-01-07 0:06 bangerth 2003-01-06 23:56 Gerald Pfeifer 2002-12-27 11:56 Gerald Pfeifer 2002-12-10 16:19 bangerth 2001-08-09 7:16 pfeifer
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=20030106224602.16913.qmail@sources.redhat.com \ --to=bangerth@ticam.utexas.edu \ --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).