This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Using bugzilla to track XFAILs
- From: "Giovanni Bajo" <giovannibajo at libero dot it>
- To: "Ian Lance Taylor" <ian at wasabisystems dot com>,<Richard dot Earnshaw at arm dot com>
- Cc: <gcc at gcc dot gnu dot org>,"Mark Mitchell" <mark at codesourcery dot com>,"Gabriel Dos Reis" <gdr at integrable-solutions dot net>,"Zack Weinberg" <zack at codesourcery dot com>
- Date: Fri, 13 Feb 2004 18:30:29 +0100
- Subject: Re: Using bugzilla to track XFAILs
- References: <200402131613.i1DGDfT13051@pc960.cambridge.arm.com> <m3ekszlzfo.fsf@gossamer.airs.com>
Ian Lance Taylor wrote:
>> I like the idea also, but we need to make sure we do it carefully.
>> Often a test is xfailed when it isn't really a problem with the
>> compiler but with the run-time environment. Take, for example,
>> g77.f-torture/execute/io0.f, which is xfailed on several embedded
>> platforms because there is no support for stat() in these
>> environments.
>
> I think the proper result for such a test--one which only makes sense
> when certain facilities are available--is UNSUPPORTED.
Yes, but there is a conceptual difference between UNSUPPORTED, XFAIL and KFAIL.
UNSUPPORTED (which is { target whatever-triplet-here }) should be used for a
test which is for a feature which is unavailable on the system. For instance, a
test about SSE compilation should be marked as unsupported on PowerPC
platforms. XFAIL should be used for tests which are supposed to work, but don't
for external reasons (like a bug in the external tools, libraries, operating
system or whatever). KFAIL is instead the "shut up, I'll fix you later" which
we should track in Bugzilla.
I agree with Richard that we need to carefully discriminate between XFAIL and
KFAIL, even if there is no way to track them right now (since our required
DejaGnu version doesn't support KFAIL). I will remember this while writing the
policy.
Giovanni Bajo