This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.1: Buildable on GHz machines only?
- From: Daniel Jacobowitz <drow at false dot org>
- To: Matt Thomas <matt at 3am-software dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 26 Apr 2005 22:57:07 -0400
- Subject: Re: GCC 4.1: Buildable on GHz machines only?
- References: <426EFE00.firstname.lastname@example.org>
On Tue, Apr 26, 2005 at 07:50:40PM -0700, Matt Thomas wrote:
> Over the past month I've been making sure that GCC 4.1 works on NetBSD.
> I've completed bootstraps on sparc, sparc64, arm, x86_64, i386, alpha,
> mipsel, mipseb, and powerpc. I've done cross-build targets for vax.
> Results have been sent to gcc-testsuite.
> The times to complete bootstraps on older machines has been bothering me.
> It took nearly 72 hours for 233MHz StrongArm with 64MB to complete a
> bootstrap (with libjava). It took over 48 hours for a 120MHz MIPS R4400
> (little endian) with 128MB to finish (without libjava) and a bit over 24
> hours for a 250MHz MIPS R4400 (big endian) with 256MB to finish (again,
> no libjava). That doesn't even include the time to run the testsuites.
> I have a 50MHz 68060 with 96MB of memory (MVME177) approaching 100 hours
> (48 hours just to exit stage3 and start on the libraries) doing a bootstrap
> knowing that it's going to die when doing the ranlib of libjava. The kernel
> for the 060 isn't configured with a large enough dataspace to complete the
> Most of the machines I've listed above are relatively powerful machines
> near the apex of performance of their target architecture. And yet GCC4.1
> can barely be bootstrapped on them.
Note that the MIPSen are not near the top of modern MIPS performance.
The ARM isn't quite there either, but the higher-powered ARMs are a bit
scarcer than the MIPS.
None of this detracts from your point, though.
> I'm going to run some bootstraps with --disable-checking just to see how
> much faster they are. I hope I'm going to pleasantly surprised but I'm
> not counting on it.
I would expect it to be drastically faster. However this won't show up
clearly in the bootstrap. The, bar none, longest bit of the bootstrap
is building stage2; and stage1 is always built with optimization off and
(IIRC) checking on.