From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2382 invoked by alias); 2 May 2005 08:42:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2204 invoked from network); 2 May 2005 08:41:45 -0000 Received: from unknown (HELO nef2.ens.fr) (129.199.96.40) by sourceware.org with SMTP; 2 May 2005 08:41:45 -0000 Received: from quatramaran.ens.fr (quatramaran.ens.fr [129.199.129.64]) by nef2.ens.fr (8.13.2/1.01.28121999) with ESMTP id j428fiLT044305 for ; Mon, 2 May 2005 10:41:44 +0200 (CEST) Received: by quatramaran.ens.fr (Postfix, from userid 561) id 1F5EFE257; Mon, 2 May 2005 10:41:44 +0200 (CEST) To: gcc@gcc.gnu.org Subject: Re: GCC 4.1: Buildable on GHz machines only? X-Newsgroups: ens.mailing-lists.egcs.general In-Reply-To: <17007.61667.295386.348123@gargle.gargle.HOWL> References: <20050427152844.GA86951@compsoc.man.ac.uk> <426FB37D.3060507@3am-software.com> <200504272157.21513.s.bosscher@student.tudelft.nl> Cc: Message-Id: <20050502084144.1F5EFE257@quatramaran.ens.fr> Date: Mon, 02 May 2005 08:42:00 -0000 From: espie@quatramaran.ens.fr (Marc Espie) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 02 May 2005 10:41:44 +0200 (CEST) X-SW-Source: 2005-05/txt/msg00030.txt.bz2 In article <17007.61667.295386.348123@gargle.gargle.HOWL> you write: >The alternative of course is to do only crossbuilds. Is it reasonable >to say that, for platforms where a bootstrap is no longer feasible, a >successful crossbuild is an acceptable test procedure to use instead? No. I've been playing enough with crossbuilds to know that a crossbuild will show you bugs that do not exist in native builds, and VICE-VERSA. Building a full system natively, compiler-included, is still one of the best stress-test for an operating system. This mind frame, that because the compiler is too slow, it's acceptable to do cross-builds, is killing older systems. Very quickly, you end up with fast, robust systems that are heavily tested through the build of lots of software, and with slow, untested systems that never see a build, and are only tested casually by people running a handful of specialized applications on them. I'm speaking from experience: you wouldn't believe how many bugs we tracked and fixed in OpenBSD on fringe platforms (arm, sparc64) simply because we do native builds and see stuff people doing cross-builds don't see. This is not even the first time I talk about this on this list. Except for embedded systems where memory and disk space don't make it practical to compile anything natively, having a compiler so slow that it makes it impossible to compile stuff natively kills old platforms. Do you know why GCC4 is deprecated on sparc-openbsd ? It's simply because no-one so far has been able to dedicate the CPU time to track down the few bugs that prevented us from switching to gcc 3.x from 2.95. That's right, I said CPU-time. It takes too long to bootstrap the compiler, it takes too long to rebuild the whole system. And thus, it rots.