> The description of WORKSFORME sounds closest: we don't know how to > reproduce the bug. Should that be used? The only other choices > are FIXED (wrong), DUPLICATE (wrong), INVALID (we don't know that), > or WONTFIX (we're not saying we won't fix it if we get a testcase). > > This came up because RMS raised a concern about the large number > of wrong-code bugs; many of those not marked "regression" are WAITING, > or should be WAITING. I'd like to knock off a few (and of course > they can be re-opened if we get more data).
Create a new case then. Afterall it can't be that hard compared to working on GCC, right? Perhaps "STUCK-FOR-MORE-INFO" would make sense. I can see "WAITING" being that either there's not enough info or not enough testcase. Even if its state is WORKSFORME, I can see adding the testcase around on some automated tester to verify the compiler doesn't bork in the future. Any bug that creates an ICE should DEFINITELY remain open, and maintainers should persue the reporter for a testcase, if only to fix/add to an automated tester. As an example, a bunch of the ColdFire "move.b, <ea>,%aY" bugs (5753 for example), with testcases, get getting hammered closed in various releases, only to pop up again in the future. Saddest is that is that in a batch of various related bug closings, the blanket comment "M68k/ColdFire is not a primary platform - CLOSED". Again, this misleads any analysis of how good GCC is as a compiler for non-primary targets. Is there a way of converting these to DEFERRED so they don't get magically CLOSED and their testcases get pulled into some automated tester? I can't see blindly punting bugs that someone has gone to at least the effort of reporting only to get ignored if no further information is forthcoming - perhaps the description of the issue is enough for some energetic intern to come along and create a testcase, who knows? -- Peter Barada [EMAIL PROTECTED]
