This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB 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]

adding KFAILs to C++ testsuite


At some point in the not-to-distant future (next week?  whenever I
emerge from grading hell and have a chance to catch my breath), I hope
to start gradually adding KFAILs to the C++ testsuite.  The goal is to
audit existing FAILs and XFAILs, to add PR's for them if necessary,
and to convert them over to KFAILs when appropriate (which should be
most of the time).  And I'll go in the other direction as well: if a
C++ PR doesn't have a testsuite test for it, I'll add a KFAILed one
for it.

I wanted to double-check that I understand when KFAIL is appropriate
and when XFAIL or FAIL is appropriate.  My understanding is that KFAIL
is almost always the appropriate choice; I asked Michael Chastain
about this, and he said the following:

> An XFAIL means that we have found a bug in software external to
> gdb.

> UNSUPPORTED means something like "this configuration does not intend
> to support this behavior".

> KFAIL means that the failure is due to a known bug in gdb, which
> implies that it's accompanied by a gdb PR #.

> My notion of a bug lifecycle is that each FAIL gets either fixed or
> turned into a KFAIL pretty aggressively.  So that at any given
> moment, the FAIL's are all things that haven't been analyzed yet.

Please let me know if my understanding on this issue is incorrect, or
if you disagree with this plan.

David Carlton
carlton@math.stanford.edu


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