From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
To: zack@codesourcery.com
Cc: gcc@gcc.gnu.org
Subject: Re: ACATS legal status cleared by FSF
Date: Thu, 06 Dec 2001 15:40:00 -0000 [thread overview]
Message-ID: <10112062313.AA04531@vlsi1.ultra.nyu.edu> (raw)
I'm 100% confident that there is value to having "make check" drive at
least some set of Ada tests.
I don't think *anybody* disagrees with that. The question is what should
that subset be? My experience with backend changes is that most of the
failures are in C3, CD, CXA, and CXG, with a smaller number in C4. For
changes to other than the Ada front-end, the benefit of running additional
chapters is, in my opinion, small. I can't remember a time when a backend
change caused an ACATS failure that didn't show up in one of those chapters.
That being said, I should also point out that the ACATS suite isn't a very
good test of the back-end at all, but perhaps running it with different
optimization levels will help.
(with the implication that writing a C testcase is impossible or at
least too much work).
Usually impossible. The issue is trees that can't be made in C, such as with
PLACEHOLDER_EXPR.
It may make sense not to run the ACATS B tests by default, but they
should at least be _present_ in the repository so that everyone is on
an equal footing for changes that affect error messages.
I think everybody agrees with that too, but the question is what does
"present" mean with respect to the baselines, which is where the real
maintenance issue is.
next reply other threads:[~2001-12-06 23:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-06 15:40 Richard Kenner [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-09 14:00 dewar
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: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=10112062313.AA04531@vlsi1.ultra.nyu.edu \
--to=kenner@vlsi1.ultra.nyu.edu \
--cc=gcc@gcc.gnu.org \
--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).