Re: Bug triage

[Jeff Law <law at redhat dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/11 14:06, Tony Poppleton wrote:
> 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.
For missed-optimization bugs this can indeed be difficult.  Often you
have to have debugged things far enough to know the exact effect you're
looking for.  Then reduce the testcase and verify the
missed-optimization at each step.

The reduction step is significantly easier for for other bugs, with ICEs
being the easiest.


> 
> 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.
The easiest way is to use the PR # in the testcase's name.  ie
pr12345.C

> 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.
You've hit on a real issue.  It may be beneficial to keep even more
compiler versions hanging around.  The head of each stable release
branch, the last release from each stable release branch and the head of
the trunk.

You can test with the head of each release branch, if it fails there,
then I'd assume it also fails with the latest release from that branch.

But I think the key is to just keep the necessary builds hanging around,
at least for the most popular targets.

> 
>> 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?
Yes.  And note that getting this wrong isn't a fatal problem.  The
absolute worst that happens is someone comes along and realizes the
testcase is invalid, a duplicate or something like that.

> 
> 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.
Andrew or Steven probably should have marked it as confirmed.

> 
> 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)?
Seems reasonable.  It wouldn't be a bad idea for someone more
experienced to look at the problem and verify there isn't a more general
issue.

If the underlying issue is indeed the asm, then lowering the priority
might be reasonable.  If instead there's a general situation where
swapping the register loads in reg-stack would prove profitable in code
without asms, then it should be a higher priority.

jeff


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNKy76AAoJEBRtltQi2kC7hEwIAJN5xK3C7bEjS+QLyaM/bJjO
dBFxwZe+IeBbTPYullTANmqffoN5I4v2rQ+5Vd6mfQ7jX/PkbrjSBP9JgAW76zRN
aeMM+/me+ksMHWb2D2/6qTtQfIsGwMZFr9D/9r7pggr41gS6Kmn3tAFL17nP/Z5x
xeZLC6+Hu94LIMdl2nYWcwqPDkTOhGnUEybJ5cpG6t097nBualxgRfEa/LkZZT3T
mTPyvT9W/VKD9XBDSpekSQjXVT8x8U26PQzBP1ccI80oJ8UUXBYUpZ/EJxhbfDci
BfeG59/g27LuBg8bK/b+yl5Q5uGXzbP21M6k6E3yDQBaJZWadJ9qGuRNQqkJskM=
=m3BU
-----END PGP SIGNATURE-----