From: David Carlton <carlton@kealia.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: dejagnu@gnu.org, gdb@sources.redhat.com,
Fernando Nasser <fnasser@redhat.com>
Subject: Re: Print KFAIL's in dejagnu summary?
Date: Mon, 29 Sep 2003 19:46:00 -0000 [thread overview]
Message-ID: <yf2lls7phhw.fsf@hawaii.kealia.com> (raw)
In-Reply-To: <3F759D90.8050203@redhat.com> (Andrew Cagney's message of "Sat, 27 Sep 2003 10:24:16 -0400")
On Sat, 27 Sep 2003 10:24:16 -0400, Andrew Cagney <ac131313@redhat.com> said:
>> On Thu, 25 Sep 2003 17:44:27 -0400, Andrew Cagney <ac131313@redhat.com> 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
next prev parent reply other threads:[~2003-09-29 19:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-25 21:56 Andrew Cagney
2003-09-26 0:03 ` David Carlton
2003-09-27 15:46 ` Andrew Cagney
2003-09-29 19:46 ` David Carlton [this message]
2003-09-27 10:34 ` Jim Blandy
2003-10-03 15:52 ` Rob Savoye
2003-09-25 22:13 Michael Elizabeth Chastain
2003-09-29 20:05 Michael Elizabeth Chastain
2003-10-03 15:57 Michael Elizabeth Chastain
2003-10-03 16:06 ` Rob Savoye
2003-10-03 23:28 ` Ben Elliston
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yf2lls7phhw.fsf@hawaii.kealia.com \
--to=carlton@kealia.com \
--cc=ac131313@redhat.com \
--cc=dejagnu@gnu.org \
--cc=fnasser@redhat.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox