This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Suggestion for a new GNATS policy


Daniel Berlin <dberlin@dberlin.org> wrote:

>>   "analyzed" should mean that at least the category is set and
>> that a reduced test case is available.

> Why?
> you can mark them with a keyword or bug status flags.
> Stop overloading bug states for this functionality.
> Geez.

No, in my opiniton it's totally the contrary. "Confirmed" should be just a
flag. I don't care if a bug is confirmed or not: confirming is a no-brain
action: it means I downloaded the PR, run GCC on it, and verified the bug.
To push it, it could even be automated for c++/c/middle-end/optimization
bugs (especially ICEs). I don't think anybody really cares if it's been
confirmed that a 300K file ICEs the compiler: the real problem is an
effective analysys of the bug, which means testcase reduction, code forming
check, and such.
This is what it's really important. I don't really mind about the name, but
if Bugzilla doesn't have "analyzed" but only "uncorfimed" and "new", we
should use "new" as analyzed.

Otherwise, please explain us what is a state and what is a flag. Usually, a
bug which is not properly analyzed will not be considered for bugfixing, so
this is where the stress should go. I call this a bug state. Confirmation is
not necessary a state (it's mostly useless), so I'm ok with it being just a
flag.

Giovanni Bajo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]