Bug triage

[Tony Poppleton <tony dot poppleton at gmail dot com>]

Hi,

I would like to help with some gcc bug triage, and have a few
questions about doing so.

1. My plan is to start testing bugs against the latest stable build
(4.5.2), on an Intel x86-64 architecture (possibly also testing 32 bit
bugs).  My main focus will be on "missed-optimizations", although I
will try and do others too.  I have read the
http://gcc.gnu.org/bugs/management.html page, so it seems the main
thing I will be doing is setting one of the "Known to pass/fail"
fields to "4.5.2".

Is there anything else that I can do that would be of use to gcc
developers? (short of fixing the bug : )

For example, in cases where a bug doesn't have a test case as an
attachment, but instead embedded in the description, would it be of
use for me to create the attachment?

2. A large number of bugs seem to not be targetted for any particular
release, e.g. of the 4389 open bugs, only 296 are listed as targetted
for 4.6.0.  Why is there such a discrepency?

Incidentally, my main focus will be on these untargetted bugs rather
than on bugs that are already scheduled to be fixed.

3. If I mark a bug as known to fail in 4.5.2, will someone else then
schedule it to be fixed in 4.6.0?

4. In general, who is responsible for setting the target release field?

5. Similarly, if I mark a bug as known to work in 4.5.2, will this
lead to it eventually being closed?

Thanks,
Tony