From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22589 invoked by alias); 30 Aug 2004 22:52:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 22580 invoked from network); 30 Aug 2004 22:52:11 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sourceware.org with SMTP; 30 Aug 2004 22:52:11 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id 2708AF2E04; Mon, 30 Aug 2004 18:52:11 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03026-01-4; Mon, 30 Aug 2004 18:52:10 -0400 (EDT) Received: from [127.0.0.1] (ppp3.gnat.com [205.232.38.213]) by nile.gnat.com (Postfix) with ESMTP id C62B7F2DF5; Mon, 30 Aug 2004 18:52:07 -0400 (EDT) Message-ID: <4133AF9E.1020304@gnat.com> Date: Mon, 30 Aug 2004 22:56:00 -0000 From: Robert Dewar User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 MIME-Version: 1.0 To: Mike Stump Cc: Richard Kenner , gcc@gcc.gnu.org, jsm@polyomino.org.uk Subject: Re: Ada policy References: <10408302121.AA00131@vlsi1.ultra.nyu.edu> <36FED0BE-FAD5-11D8-8516-000393941EE6@apple.com> In-Reply-To: <36FED0BE-FAD5-11D8-8516-000393941EE6@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-08/txt/msg01543.txt.bz2 Mike Stump wrote: > On Aug 30, 2004, at 2:21 PM, Richard Kenner wrote: > >> second that nearly all of the test cases are proprietary code. > > > Yes, and this was true of quite a few of the C/C++ testcases too... > but, this doesn't relieve the obligation to add a test case. > > Don't start fixing a testcase until after you've trimmed the testcase > down, then you will find that all bugs you fix will have cut down test > cases. A few bug fixes will never have testcases, that is fine. A good > example is a memory smasher that randomly goes in and out of workingness > as the testcase is changed. These will not usually have a testcase. > However the vast majority of the rest can have a minimal testcase > produced. A few will need 12 hours to cut down the testcase, the bulk > of them should be substantially easier. It's simply a matter of not having the resources to follow this desirable approach. > Sometimes there will be areas where the testing infrastructure doesn't > support testing, for which you'll just skip adding tests, this too is > fine to a degree. In C/C++, this is done with stuff like cross module > or cross shared library issues... Not perfect, but the best we can do > at the moment. In time, we'll have a driver even for that. > > We can describe the procedure to transform a proprietary testcase in > detail into one that isn't, if you want. There is an algorithm. > Roughly, get testcase, remove every function, variable, block, > statement, argument that can be that doesn't affect the testcase. > Understand why what's left is minimal as you fix the bug, then try and > recode the testcase to make the things that happen to be true, to be > true. For example, need register pressure, insert canonical code to > increase pressure... Mostly works for me. It is greedy, and has near > linear cost. Further, at times, people automate it in various ways > (delta, slice)... If it is a hardship, pick an automation to handle the > grunt work, or an intern... Even a language agnostic one that just runs > the algorithm line by line might be enough for you... One that is done > change all variable/function/type names and then examine code to be sure > that no trade secrets or original structure or original intent, use or > meaning is left that the customer would care about, if in doubt, just > ask them directly. Again, we don't need to know how this is done, we know perfectly well. We simply don't have the resources to do it (even keeping the trees syncrhonized is a huge amount of work). > So, I guess I am confused as to, do you just not want to do the work to > produce the testcases, or do you lack the understanding of how to do it? It is not a matter of what we want, it is a matter of what we have the resources to provide. > As for the past, I'd say that while it would be nice to get more of the > Ada testcase that you have into the the FSF testsuite, I think it is > reasonable to merely require this of _new_ bugfixes to new > bugs/regressions. But as I mentioned before, the practical effect of this requirement, if you make it a requirement is that fixes will simply not get transferred to the FSF tree in many cases. Mike, I encourage you to examine, in detail, typical front end fixes, which is what we are talking about here. I think the concern is more theoretical than actual.