From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17570 invoked by alias); 30 Dec 2002 16:09:54 -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 17563 invoked from network); 30 Dec 2002 16:09:54 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 30 Dec 2002 16:09:54 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18T4Mf-0003GW-00; Mon, 30 Dec 2002 12:10:13 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18T2U0-0008Ur-00; Mon, 30 Dec 2002 11:09:40 -0500 Date: Mon, 30 Dec 2002 11:41:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: gdb.c++/main-falloff.exp (a new KFAIL) Message-ID: <20021230160940.GA32617@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <200212301604.gBUG4s303613@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212301604.gBUG4s303613@duracef.shout.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00757.txt.bz2 On Mon, Dec 30, 2002 at 10:04:54AM -0600, Michael Elizabeth Chastain wrote: > Hi Daniel! > > > First of all, KFAIL is (in my opinion) for things that we have analyzed > > and established to be known bugs _in the tool under test_. That's what > > differentiates them from XFAILs; I thought that was the consensus. > > You are right. I am mixing two issues here. I agree with you, > but my code doesn't. :-( > > I would like to file a gcc bug on this and then it would be an xfail. > It's only a kfail because I am so conservative about marking bugs > as "gdb bugs" until proven otherwise. In the past we have been > lax about blaming things as xfail prematurely. > > > I.E. the "return 0" is outside of the lexical block for main. That's > > not necessarily wrong. We have to decide if it is wrong - whether the > > test case should be updated or a GCC bug report filed. My inclination > > is that it's a GCC bug. > > Me too. How about if I file it as such, and then make this an XFAIL? > > > GDB is behaving exactly as expected given its inputs; ergo, this is not > > a KFAIL at all. > > POW. Ya got me. > > > What do you think of: > > gdb_test_multiple "info locals" \ > > {pass "(i|j|k) = (101|102|103)\r\n(i|j|k) = (101|102|103)\r\n(i|j|k) = (101|102|103)" > > kfail "gdb/900" "No locals."} \ > > "testing locals" > > I am open to new syntax. I do prefer gdb_test to send_gdb/gdb_expect. > I never thought of extending the gdb_test idea but it's a good idea. > > So if you're cool with me filing a gcc bug report, I can s/kfail/xfail/, > close PR gdb/900 as "not a gdb bug -- see PR gcc/9NNN", and we can > wrangle about gdb_test_multiple. > > I will definitely suspend committing this for a while. Sounds good to me. Give me about an hour first; I'm looking at the GCC bug. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer