This is the mail archive of the
mailing list for the GDB project.
Re: Print KFAIL's in dejagnu summary?
On Sat, 27 Sep 2003 10:24:16 -0400, Andrew Cagney <firstname.lastname@example.org> said:
>> On Thu, 25 Sep 2003 17:44:27 -0400, Andrew Cagney <email@example.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
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).