From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28684 invoked by alias); 3 Jan 2003 21:48:42 -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 28677 invoked from network); 3 Jan 2003 21:48:41 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 209.249.29.67 with SMTP; 3 Jan 2003 21:48:41 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h03LmPd31766; Fri, 3 Jan 2003 13:48:25 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, Michael Elizabeth Chastain Subject: Re: [patch/rfc] KFAIL gdb.c++/annota2.exp watch triggered on a.x References: <20030103213920.GA21687@nevyn.them.org> From: David Carlton Date: Fri, 03 Jan 2003 21:48:00 -0000 In-Reply-To: <20030103213920.GA21687@nevyn.them.org> 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: 2003-01/txt/msg00095.txt.bz2 On Fri, 3 Jan 2003 16:39:20 -0500, Daniel Jacobowitz said: > May I recommend at the least "i?86"? That makes sense. > Also, I really don't see the point of the kpass's; before doing > this, you need to establish if those patterns are acceptable > results; if so, they are passes, period. Sorry, I should have explained my reasoning there. My theory behind that is that they're a reminder to people who fix bugs that they should update the test suite. If somebody fixes this bug a year from now, doesn't know that there's a test case for the bug, and doesn't pay attention to gdb.sum (just to the naked 'make check'), then that person might easily forget to update the test suite. (Especially since the test case in question is in gdb.c++/annota2.exp, whereas the bug doesn't involve either C++ or annotations!) So it seems to me that, if the failure isn't reliable, then we should leave the success case as a PASS, but if the failure is reliable, then KPASS is slightly better. David Carlton carlton@math.stanford.edu