This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]