This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Using bugzilla to track XFAILs
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: "Giovanni Bajo" <giovannibajo at libero dot it>, 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>, Richard dot Earnshaw at arm dot com
- Date: Fri, 13 Feb 2004 16:13:41 +0000
- Subject: Re: Using bugzilla to track XFAILs
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> "Giovanni Bajo" <giovannibajo@libero.it> writes:
>
> > There must be a better way to not forget about them. I propose the introduce a
> > new policy: for each regression which has been xfailed in the testsuite, there
> > ought be a bugzilla bug referencing it. We already have a keyword called
> > 'xfail', but it is currently used only by the tree-ssa branch.
>
> I second this proposal.
>
> Ian
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.
Ideally such tests should be skipped when the compiler is not at fault.
Another possibility might be to use the KFAIL feature introduced into
dejagnu for gdb. A kfail (known failure) could require a PR to be
associated with it.
R.