Tony Poppleton <tony.popple...@gmail.com> writes: > 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?
Moving the test case into an attachment won't be useful. What would be useful is recasting the test case into a form which can be used in the gcc testsuite, if possible. That can be hard for a missed-optimization bug. In some cases you can do it by scanning the final assembler file. In other cases you have to resort to scanning dump information. And sometimes there is just no reasonable test. But when you can create a test case for a bug, it makes it far less likely that the missed optimization will return in a later release. > 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. For an open bug, a target of 4.6.0 means only that the bug is known to fail on current mainline. It doesn't mean that the bug is more likely to be fixed for 4.6.0 than any other current bug. At least, as far as I know; the release managers or bugmasters may have a better idea. > 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? No. People choose bugs to work on based mainly on the priority and on whether the bug is a regression or not. As far as I know people do not look at the target field. > 4. In general, who is responsible for setting the target release field? The bugmasters, if anybody. > 5. Similarly, if I mark a bug as known to work in 4.5.2, will this > lead to it eventually being closed? Yes, when the 4.4 release is closed, bugs known to work in 4.5 will be closed. Thanks very much for volunteering to look at this. It is very helpful. Ian
