Managing Bugs (Bugzilla and the testsuite)

This section contains information mostly intended for GCC contributors.

Reporting and Fixing Bugs

If you find a bug, but you are not fixing it (yet):

Create a (minimal) testcase and add a bug report including it to the bug database (Bugzilla).

If you want to provide additional information about a bug in the database:

If the bug is a segmentation fault in the compiler, provide information about its location.
Minimize the test case.
Try the test case with earlier and later versions of GCC to determine which versions it affects and whether it is a regression.
If it is a regression, identify the patch that introduced it.

If you fix a bug:

Check in your fixes.
If there is already a testcase in the testsuite, remove the XFAIL. Else, create a minimal testcase (maybe the bug database already provides one) and add it to our testsuite, marking it as PASS.
If there is an associated bug report in the database, close it.

Maintainer's View of Fields

Bugzilla offers a number of different fields. From a maintainer's perspective, these are the relevant ones and what their values mean:

Status	Resolution
The status field indicates the general health of a bug. Only certain status transitions are allowed.	The resolution field indicates what happened to this bug.
UNCONFIRMED The PR has been filed and the responsible person(s) notified. NEW A maintainer has verified that this is indeed a bug in GCC. Every once in a while, old reports will need to be rechecked, to find out whether the bug still exists. WAITING The submitter was asked for further information, or asked to try out a patch. The PR remains in that state until the submitter responds. SUSPENDED Work on the problem has been postponed. This happens if a timely solution is not possible or is not cost-effective at the present time. The PR continues to exist, though a solution is not being actively sought. If the problem cannot be solved at all, it should be closed rather than suspended. ASSIGNED This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED. REOPENED This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED.	No resolution yet. All bugs which are in one of these "open" states have the resolution set to blank. All other bugs will be marked with one of the following resolutions.
RESOLVED A resolution has been found for this bug. The bug is either closed for good, or can be re-opened and change to REOPENED.	FIXED A fix for this bug is checked into the tree and tested. INVALID The problem described is not a bug. WONTFIX The problem described is a bug which will never be fixed. DUPLICATE The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug# of the duplicating bug and will at least put that bug number in the description field. WORKSFORME All attempts at reproducing this bug were futile, reading the code produces no clues as to why this behavior would occur. If more information appears later, please re-assign the bug, for now, file it.

The following two fields describe how serious a bug is from a user's perspective (severity) and which priority we assign to it in fixing it:

Severity

This field describes the impact of a bug.

Critical	crashes, memory leaks and similar problems on code that is written in a common enough style to affect a significant fraction of users
Normal	major loss of functionality
Minor	minor loss of functionality, misspelled word, or other problem where an easy workaround exists
Enhancement	Request for enhancement

Priority

This field describes the importance and order in which a bug should be fixed. It is utilized by the programmers/engineers to prioritize their work to be done. The available priorities are:

P1	Most important
P2
P3	Least important

Assigned To

This is the person in charge of resolving the bug. Every time this field changes, the status changes to NEW to make it easy to see which new bugs have appeared on a person's list.

Keywords

These are used to further classify the problem reports. Follow the link for a complete list of the keywords including descriptions.

Procedures and Policies

Putting reports in components "C", "C++", and "optimization" in state "NEW" requires that there is a reduced, small testcase. This makes sure that all NEW reports are really analyzed and are ready to be handed off to the people actually fixing bugs.

Regressions should be explicitly marked as such. The summary line should read

[branches-to-fix regression] rest-of-summary

where branches-to-fix is the list of maintained branches (separated by slashes) that need fixing. A regression should start with severity "critical" to bring it to attention. It may be downgraded later if a defect is not important enough to justify "critical" severity. In addition the target milestone should be set to the next release of the newest active release branch that needs fixing (the rationale is that a patch will have to go to the newest release branch before any other release branch). The milestone can be changed by the release manager and his/her delegates.

If a patch fixing a PR has been submitted, a link to the message with the patch should be added to the PR, as well as the keyword "patch".

Meta-bugs (reports with the keyword "meta-bug") are used to group PRs that have a common denominator. Meta-bugs do not have testcases of their own, but provide links to regular PRs via Bugzilla's "depends on/blocks" mechanism instead: they depend on the regular PRs. Information concerning the majority of bugs blocking a meta-bug should be added to the meta-bug instead of each single PR.

Bugs with keyword "ice-on-invalid-code", where GCC emits a sensible error message before issuing an ICE (the ICE will be replaced by the message "confused by earlier errors, bailing out" in release versions) should get "minor" severity and the additional keyword "error-recovery".

Bugs in component "bootstrap" that refer to older releases or snapshots/CVS versions should be put into state "WAITING", asking the reporter whether she can still reproduce the problem and to report her findings in any case (whether positive or negative).

If the response is "works now", close the report,
if the response is "still broken", change the state to "NEW", and
if no response arrives, close the PR after three months.

Bugs that are in state "WAITING" because they lack information that is necessary for reproducing the problem can be closed if no response was received for three months.

When closing a PR because it got fixed, please set the target milestone to the first release where it will be/has been fixed. Also adjust the target milestone when a fix is backported.

Duplicate PRs should be marked as such. If you encounter a PR that is marked as "resolved fixed", but should be marked as a duplicate, please change the resolution. (You have to reopen the PR before you can resolve it as a duplicate.)

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

These pages are maintained by the GCC team.

For questions related to the use of GCC, please consult these web pages and the GCC manuals. If that fails, the gcc-help@gcc.gnu.org mailing list might help.
Please send comments on these web pages and the development of GCC to our developer mailing list at gcc@gnu.org or gcc@gcc.gnu.org. All of our lists have public archives.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Last modified 2006-06-21