public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Diego Novillo <dnovillo@google.com>
To: gcc@gcc.gnu.org
Subject: RFC: Improving support for known testsuite failures
Date: Wed, 07 Sep 2011 15:28:00 -0000	[thread overview]
Message-ID: <20110907152813.GA28540@google.com> (raw)

One of the most vexing aspects of GCC development is dealing with
failures in the various testsuites.  In general, we are unable to
keep failures down to zero.  We tolerate some failures and tell
people to "compare your build against a clean build".

This forces developers to either double their testing time by
building the compiler twice or search in gcc-testresults and hope
to find a relatively similar build to compare against.

Additionally, the marking mechanisms in DejaGNU are generally
cumbersome and hard to add.  Even worse, depending on the
controlling script, there may not be an XFAIL marker at all.

So, while we would ideally keep NO failures in the testsuite, the
reality is that we are content with having KNOWN failures.  For a
given set of failures out of 'make check', I would like to have a
simple filtering mechanism that prunes the known failures out.

Desired features:

- List of known failures lives in SVN.
- Each target can have its own list.
- Supports ignoring FAIL, UNRESOLVED and XPASS results.
- Supports pattern matching to glob sets of failures.
- Co-exists with the existing XFAIL support in DejaGNU.
- Supports flaky tests.
- Supports timestamps to avoid having tests in a knonw-to-fail
  state forever.

In terms of implementation, this filter could be part of 'make
check'.  We'd pipe make check's output to it and it would decide
whether to emit FAIL/UNRESOLVED/XPASS lines based on the black
list.

I could also make this a post-check filter that runs on all the
generated <tool>.sum files.  The filter could live in
<src>/contrib and be used on demand.

I am not thrilled about the prospect of implementing this in
DejaGNU directly.

Thoughts?


Thanks.  Diego.

             reply	other threads:[~2011-09-07 15:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-07 15:28 Diego Novillo [this message]
2011-09-07 18:43 ` Andreas Jaeger
2011-09-07 19:57 ` Joseph S. Myers
2011-09-08  8:31 ` Richard Guenther
2011-09-08 11:05   ` Diego Novillo
2011-09-08 11:16     ` Richard Guenther
2011-09-08 11:34       ` Diego Novillo
2011-09-08 11:49         ` Richard Guenther
2011-09-08 12:14           ` Diego Novillo
2011-09-08 12:20             ` Richard Guenther
2011-09-08 12:26               ` Diego Novillo
2011-09-08 12:30                 ` Richard Guenther
2011-09-08 12:33                   ` Diego Novillo
2011-09-08 13:24         ` Richard Earnshaw
2011-09-08 13:55           ` Diego Novillo
2011-09-08 14:03             ` Richard Earnshaw
2011-09-08 16:41           ` Joseph S. Myers
2011-09-23  0:07     ` Hans-Peter Nilsson
2011-09-23 13:11       ` Diego Novillo
2011-09-08 16:39   ` Joseph S. Myers
2011-09-08 22:27   ` Michael Hope

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=20110907152813.GA28540@google.com \
    --to=dnovillo@google.com \
    --cc=gcc@gcc.gnu.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).