This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.1: Buildable on GHz machines only?
>>>>> "Steven" == Steven Bosscher <s.bosscher@student.tudelft.nl> 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