From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21695 invoked by alias); 24 Oct 2002 21:39:44 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21671 invoked from network); 24 Oct 2002 21:39:43 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 24 Oct 2002 21:39:43 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g9OLdXN31715; Thu, 24 Oct 2002 14:39:33 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/ References: <3DB83EC1.6070609@redhat.com> From: David Carlton Date: Thu, 24 Oct 2002 14:39:00 -0000 In-Reply-To: <3DB83EC1.6070609@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00521.txt.bz2 On Thu, 24 Oct 2002 14:41:05 -0400, Andrew Cagney said: > GDB's testsuite is known to be full of xfails that are really kfails > or testsuite bugs. Rather than try to audit each xfail in turn, the > proposal as been to rip out all the xfails (creating a clean slate) > and start marking up the tests from scratch - two steps forward but > first one step back. Can you give me a little guidance here? Elena recently made the suggestion that I should add tests to the testsuite for namespace stuff, even before I've modified GDB to handle that. That sounded sensible to me, so I added that to a branch, and marked them all as xfail. I suspect I was wrong about that, though I'm not sure about the subtleties of what xfail is actually supposed to mean. I was thinking I should go and change them to kfail, but now I'm not confident that I know the intended semantics of that, either. Is kfail only allowed for tests with a PR associated to them? Admittedly, in a branch, xfail and kfail mean whatever I want them to mean, I suppose, and I'm not going to try to get those tests added to the mainline unless I can bring along much of the code that cause them to pass instead of fail. I guess I don't see the point in removing xfails from the testsuite: it's useful information, it doesn't make regression testing any harder (there, the main culprit is the !@#%# schedlock test), so why throw that away? If xfail has the wrong meaning, then change it to kfail; if kfail also has the wrong meaning, then change the meaning of kfail. David Carlton carlton@math.stanford.edu