Thanks for the feedback. > 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
Whilst I would like to be able to submit new test cases as I go, as you (Ian) pointed out this may be too difficult for missed-optimization bugs as I cannot confirm if the assembler is fixed - I can only confirm if it shows the inefficiency as listed in the bug description. Anyway, I will see what I can manage. Out of interest, is there a way of linking bugs in the bug database with their test case in the gcc test-suite, and vice-versa? There doesn't appear to be a field for this in the bug report. > > 5. Similarly, if I mark a bug as known to work in 4.5.2, will this > > lead to it eventually being closed? Just to clarify what Joseph was saying on this point, it seems that in order to help close off any bugs, I would need to run the test on 4 versions of gcc; 4.3.5, 4.4.5, 4.5.2 and trunk (4.6.0), and confirm it works for all of them. What exact gcc code should I use for this? - the latest stable build for each version? - or, the latest code from each branch? - or, the latest snapshot release for each branch? It seems to me there are pros and cons of each, so it isn't clear which is the best one. In particular, if I don't use a stable release branch, then what version should I put for the "Known to fail/work"? For example, if I use the trunk and I mark bugs as "Known to fail" in "4.6.0", and the bug is eventually fixed before 4.6.0 is shipped, then the field will be incorrectly set. > There are very many UNCONFIRMED bugs. If you can confirm that such a > bug really is a bug in GCC and is still present on trunk, then moving it to > NEW is useful. Whilst I would like to be able to do this, as a first time contributor to the project do I really have the authority to mark a bug as NEW? Otherwise what is stopping the original reporter from just marking the bug as NEW and effectively skipping the UNCONFIRMED state all together? I have a few more questions about the whole bug management process and how I may contribute... To take a random example, enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26902 has been open since 2006, it has a fairly comprehensive list of "known to fail" versions (presumably versions that were current at the time), and it has several comments. However it remains in the UNCONFIRMED state, and has never had the "Target Milestone" set. I appreciate that optimizing inline asm may be a rare use case, especially when it works without using inline asm (as per comments), however it is a valid enhancement nonetheless (and presumably the actual use case is more complicated than reported in the bug description). If I were to test this enhancement on the 4 versions of gcc and confirm it is still an open enhancment, then should it be marked as NEW, with a "Target Milestone" of 4.6.0, and the priority potentially lowered to P4 or P5 (given it is rare and old)? Regards, Tony
