PROPOSAL: Policy for obsoleting targets

[Jason Thorpe]

[ I apologize .. I'm finally catching up on GCC mail, having not had 
the time to read
   it for a about a month .. ]

On Sunday, May 18, 2003, at 07:17  AM, Marc Espie wrote:

> I'm completely against this.

I'll agree with Marc, here.

NetBSD is in a situation where we were at 2.95 for quite a long time 
for various stupid reasons (mainly "no one willing to get 
NetBSD-specific fixes into GCC mainline" for a long time ... until I 
stepped up to the task, for better or worse :-)

GCC 3.3 is the first GCC release in a VERY long time which supports the 
majority of NetBSD's supported platforms out-of-box, so you're 
certainly not going to see 3.x test results before 3.3 that cover a 
wide range of NetBSD targets.

There are other issues with testing, as well... NetBSD runs on quite a 
number of platforms, many of which are hard to find, are extremely 
slow, or consume way too much power for anyone to want to power it up 
for any length of time.  Considering how piggish GCC has become in 
terms of compile speed, it takes a REALLY long time to bootstrap on my 
HP 9000/380, only to find out at the end of a couple of days that 
libstdc++ failed to compile due to an assembler bug.

Here are what I see as some gaps in GCC testing support:

	1. There does not appear to be a pre-packaged "automated regression 
testing kit"
	   in the source tree.  For people with a limited amount of time, 
setting one up
	   can be an obstacle.  If there were a nice set of scripts and 
concise instructions
	   on how to set them up and use them, this would be a big help.

	2. It does not appear as if the testsuite is run in rsh mode very 
often.  Because
	   I have a number of slow targets to support, I really like to run 
the testsuite on
	   a host, and use the rsh method to run execute tests on the target.  
However, I
	   have run into problems with some of the tests in this type of 
configuration, and
	   I have little time to actually track them down at the moment.

	   Obviously, if the scripts mentioned in (1) supported a 
host-rsh-target setup,
	   that'd be extra cool :-)

	3. GCC's compile-time performance is so bad that it causes testsuite 
failures on
	   some platforms simply because dejagnu gives up waiting for the 
compiler to
	   finish.  I have not been able to run the testsuite on an SS20 for 
quite a long
	   time.  There's really no excuse for that.

Anyway, these three things would certainly help me provide more regular 
NetBSD test results, and would make it *possible* for me to report on 
more platforms than x86, alpha, and mipseb.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>