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/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
