From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-42404-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 26222 invoked by alias); 7 Dec 2001 01:23:21 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 26195 invoked from network); 7 Dec 2001 01:23:19 -0000
Received: from unknown (HELO nile.gnat.com) (205.232.38.5)
  by sources.redhat.com with SMTP; 7 Dec 2001 01:23:19 -0000
Received: by nile.gnat.com (Postfix, from userid 338)
	id EA5C8F28C6; Thu,  6 Dec 2001 20:22:31 -0500 (EST)
From: dewar@gnat.com
To: jsm28@cam.ac.uk, kenner@vlsi1.ultra.nyu.edu
Subject: Re: ACATS legal status cleared by FSF
Cc: gcc@gcc.gnu.org
Message-Id: <20011207012231.EA5C8F28C6@nile.gnat.com>
Date: Thu, 06 Dec 2001 17:38:00 -0000
X-SW-Source: 2001-12/txt/msg00340.txt.bz2

<Well, the ACATS tests do not check code quality, but it's correct that the B
tests verify that each condition that must produce an error message do so.
And I agree that this is worthwhile test to run.
>>

The important thing to understand is that I would say only one percent of
changes to B test output are actual errors. The remaining 99% are a result
of minor changes in error message wording, formatting, or production.

I agree with Geert that for now it is a bad idea to include the B tests.

<<It is certainly valuable to have the B tests *around* for those cases when
having a run might be useful, but requiring them as a condition for checkins
doesn't make any sense at all for changes other than to the Ada front end
(since these tests mostly don't even get out of the front end since *all* of
them have errors) and is of only marginal value for changes to the Ada front
end.
>>

I would say marginal here = not worth while