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/
 
 


             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: link
Be 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).