>>>>> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
Steven> On Wednesday 27 April 2005 22:06, Paul Koning wrote: >> Isn't a full bootstrap (all languages) part of the required test >> procedure for changes? That's what the website says right now. Steven> Isn't there a special text about port changes? Some ports Steven> don't even support all languages. http://gcc.gnu.org/contribute.html#testing does not list any special text that affects the testing rules, at least not that I can find. Yes, I suppose not all ports don't support all languages. I don't know if that's true for VAX. If so, then I would assume the rule becomes "all supported languages". Steven> What I'm saying is that if you really want/need for some Steven> reason to do full bootstraps of the latest and greatest GCC Steven> on something as old and slow as m68k (the old kind), VAX, or Steven> PDP-11, you should not complain that other people have moved Steven> on to recent targets where a bootstrap is not such a big deal Steven> and the new features in GCC make the difference between a Steven> good or poor compiler for that target. So long as the testing rules are what they are, I can't agree with that. If the testing rules are changed to allow less testing when the platform in question is slow, that's a different matter. Note that the PDP-11 case is different, that's not a native target. Also, when platform obsoletion is discussed, lack of test results is often mentioned as a metric. It seems unfair to complain about lack of test results when the software being tested is the cause (or part of the cause), not necessarily the lack of tester interest. Steven> I don't think there's any disagreement that GCC is not as Steven> fast as it should be. But bootstrapping <insert SLOC count Steven> here>[*] lines of code on a real VAX is just never going to Steven> be very fast. There is no reason to blame GCC for that. Maybe. Then again, maybe there are real problems here. The ranlib one was already mentioned. And I wonder if libjava really needs to bring the host to its knees, as it does. I normally work on a 2 GHz Linux 2.6 system. It does lots of things quite fast. I can do large system builds and do other stuff at the same time while immense makefiles are crunching away. However, I can always tell when a GCC build has hit the libjava build -- that's when the *whole system* suddenly slows to a crawl. Maybe it comes from doing some processing on 5000 foo.o files all at once... :-( paul