GCC 4.1: Buildable on GHz machines only?

[Joseph S. Myers]

On Mon, 16 May 2005, Steven Bosscher wrote:

> Just for the record, attached is gcctest's history of the overall
> memory requirement at -O[0123] for combine.i, insn-attrtab.i, and
> generate.ii (aka PR8361).  Honza's bot has been sending these
> reports since Septemper 2004, so that's where I started.

When memory consumption regresses, I think it's necessary to *file bugs in 
Bugzilla* reporting the issue, and quite likely to track down the 
responsible patch and add the responsible individual to the CC list of the 
PR.

Bots are useful, but they don't narrow things down to an individual 
patch and don't lead to the problem's existence being tracked beyond the 
immediate discussion.  Automatic regression testers are more effective 
when backed up by the people running them examining all the reported 
regressions and reporting them (less those which are already fixed or 
reported or are just noise from problems with the tester or tests which 
randomly pass or fail) to Bugzilla.

That's what I do with all testsuite regressions for C or C++ appearing on 
i686-linux, ia64-hpux, hppa2.0w-hpux or hppa64-hpux.  When a bug is 
reported this way there is a significant chance that there will be 
productive discussion involving the people responsible for causing or 
exposing the bug and leading to it being fixed.  (This doesn't always 
happen, especially for regressions only showing up on a subset of targets; 
so the reporter or someone else who cares about the problem may need to 
fix the problem someone else caused in the end.  Bugs 20605 and 21050 are 
examples of testsuite regressions affecting at least one secondary release 
platform which have the responsible patch identified but little attention 
shown.)

There has been discussion of regression testers automatically reporting 
failures to Bugzilla, and even a "regression" component existing for that 
purpose (presumably with the idea that people will refile those bugs into 
more specific components after analysis) - but there are only two open 
bugs in that component, both apparently manually reported.  From 
experience I think having people look at the regressions before reporting 
them in order at least to identify the distinct bugs involved and whether 
any are already known is desirable; at least it would avoid floods of 
automatic duplicate bugs for essentially the same issue.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)