public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: dewar@gnat.com
To: dewar@gnat.com, zack@codesourcery.com
Cc: gcc@gcc.gnu.org, kenner@vlsi1.ultra.nyu.edu, mrs@windriver.com
Subject: Re: ACATS legal status cleared by FSF
Date: Sun, 09 Dec 2001 14:00:00 -0000	[thread overview]
Message-ID: <20011209210128.BED89F28F1@nile.gnat.com> (raw)

<<I think this may be the crux of the difference between the B tests and
the existing "noncompile" tests for gcc and g++.  We - all the people
arguing for inclusion of noncompile tests - are used to a context
where it is easy to automate verification that diagnostics are
correctly issued.  When diagnostics do legitimately change, the test
harness has to be adjusted, but this is straightforward, easily done
by the person who changed the diagnostics.
>>

I don't think the noncompile tests for g++ are anything like as
comprehensive as the B tests in ACATS, which go out of there way
to test every marginal condition in the ARM. The history of these
tests is that they are done sentence by sentence against the RM,
probably there are 50,000 separate tests in all or something like
that, since many tests contain dozens of errors, and there are
thousands of tests. Furthermore, the tests were specifically
designed to check marginal cases (boundary condition testing
was the philosophy of the ACVC tests in the first place). A
consequence is that when a message changes, or disappears, or
moves to a different location, it often takes quite a bit of
expertise in the detailed semantics of Ada at the RM level to
determine whether the change is legitimate. Note that an incorrect
change to the base line, which might be of little consequence in
the g++ case, can be a serious bug in the Ada case, since it
could cause a failed validation in the future, so these baseline
changes have to be done with extreme care.

I certainly think we should upload the B tests, and we have no
problem submitting the current baselines, and people are welcome
to see whether changes they make make a difference, but I think
it is an unnecessary burden on people to require that these tests
be run, and certainly an unneccessary burden to require that the
baselines be updated.

I think the concern here is the following. The question of whether
to require/recommend/suggest that the Ada test suite be run as part
of major/minor gcc bugfix/newfeature modifications is one that needs
discussing, but I (and others familiar with the B tests) feel that
it is far better to encourage people to run the C tests, which are
likely to be far more useful, as well as executable tests that we will
provide to supplement these tests, and have more people doing this,
than having fewer people run the more onerous B tests. And certainly
the L tests should be abandoned as per previous discussion of the
subject.

I will ask Gail Schenker to provide Laurent with the current B test
baselines, and then he can do with them as he sees fit.

             reply	other threads:[~2001-12-09 21:02 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-09 14:00 dewar [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-12-09 19:03 dewar
2001-12-09 15:06 dewar
2001-12-09 15:55 ` Joseph S. Myers
2001-12-07 19:12 dewar
2001-12-09 13:02 ` Zack Weinberg
2001-12-09 14:52   ` guerby
2001-12-09 19:47     ` Geert Bosch
2001-12-07 18:57 dewar
2001-12-07 18:50 mike stump
2001-12-07 17:59 dewar
2001-12-07  3:18 Richard Kenner
2001-12-06 19:09 dewar
2001-12-06 17:38 dewar
2001-12-06 15:40 Richard Kenner
2001-12-06 15:01 Richard Kenner
2001-12-05 23:36 dewar
2001-12-05 15:28 Richard Kenner
2001-12-05 15:41 ` guerby
2001-12-05 15:13 guerby
2001-12-05 16:21 ` Joseph S. Myers
2001-12-05 18:00 ` Jerry van Dijk
2001-12-06  3:36 ` Geoff Keating
2001-12-06  9:34 ` Geert Bosch
2001-12-06 11:48   ` Zack Weinberg
2001-12-06 14:24     ` Geert Bosch
2001-12-06 14:32       ` Joseph S. Myers
2001-12-06 15:10       ` Zack Weinberg
2001-12-06 15:41         ` Geert Bosch
2001-12-06 18:22           ` Zack Weinberg

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=20011209210128.BED89F28F1@nile.gnat.com \
    --to=dewar@gnat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    --cc=mrs@windriver.com \
    --cc=zack@codesourcery.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).