From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2347 invoked by alias); 29 Sep 2003 19:29:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2276 invoked from network); 29 Sep 2003 19:29:06 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 29 Sep 2003 19:29:06 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id CADBCCB32; Mon, 29 Sep 2003 11:38:35 -0700 (PDT) To: Andrew Cagney Cc: dejagnu@gnu.org, gdb@sources.redhat.com, Fernando Nasser Subject: Re: Print KFAIL's in dejagnu summary? References: <3F7361BB.1000706@redhat.com> <3F759D90.8050203@redhat.com> From: David Carlton Date: Mon, 29 Sep 2003 19:46:00 -0000 In-Reply-To: <3F759D90.8050203@redhat.com> (Andrew Cagney's message of "Sat, 27 Sep 2003 10:24:16 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-09/txt/msg00379.txt.bz2 On Sat, 27 Sep 2003 10:24:16 -0400, Andrew Cagney said: >> On Thu, 25 Sep 2003 17:44:27 -0400, Andrew Cagney said: >>> At present KFAILs are supressed from the summary output (the stuff >>> on the terminal from "make check"). I'd like to change this so >>> that KFAILs, just like FAILs, are included in the summary. A >>> KFAIL, just like a FAIL, indicates a bug in the system under test, >>> and hence should be included in the summary. >> I have a mild preference for the current behavior. Mostly I use >> the summary output to get a feel for whether or not a change of >> mine has obviously gone wrong; the noisier the summary output is, >> the harder it is to use it this way. Of course, I always search >> the entire gdb.sum for regressions, just to make sure, so it won't >> make a big practical difference to me one way or another. > The numbers at the bottom should tell you that: > - no errors > - no unexpected passes > - no unknown failures. Right, I'm just saying that I sometimes like to look at the output while the test run is in progress. That's pretty much the only time that I do look at the output: I never pay attention to the numbers at the bottom, because once I get to that stage, I have the entire gdb.sum file available for use. > unfortunatly, the only truely robust way is to compare the .sum > files. Yes; that's one reason that my preference for the current behavior is only mild. What would make more of a difference for me (and, presumably, for other people) would be to make it as easy as possible to compare sum files: regularize the thread output a bit more, get rid of gratuitous numbers (especially the value of $fp in pc-fp.exp). David Carlton carlton@kealia.com