From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3021 invoked by alias); 14 Jan 2004 14:58:22 -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 3014 invoked from network); 14 Jan 2004 14:58:22 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sources.redhat.com with SMTP; 14 Jan 2004 14:58:22 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i0EEwL6a018572 for ; Wed, 14 Jan 2004 09:58:21 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i0EEwLIg018567; Wed, 14 Jan 2004 09:58:21 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id i0EEwL213059; Wed, 14 Jan 2004 09:58:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16389.22796.844144.901978@gargle.gargle.HOWL> Date: Wed, 14 Jan 2004 14:58:00 -0000 From: Paul Koning To: geoffk@geoffk.org Cc: gcc@gcc.gnu.org Subject: Re: gcc 3.5 integration branch proposal References: <200401132241.i0DMfbT28126@makai.watson.ibm.com> <202ADE61-461E-11D8-8072-000A95DA505C@dberlin.org> <16388.32288.690096.480227@gargle.gargle.HOWL> X-SW-Source: 2004-01/txt/msg00866.txt.bz2 >>>>> "Geoff" == Geoff Keating writes: Geoff> Paul Koning writes: >> >> * Correct code generation * Fewer ICEs * Standards conformance >> * >> Compilation speed * Performance * Features * Release >> frequency * >> Release timeliness >> >> >> >> We need to figure out how to balance those goals better without >> >> losing ground in areas where we recently have been improving. >> >> I can see why some of this ordering would be subject to >> disagreement, but I would hope that there also are partial >> orderings that are NOT debatable. >> >> The general rule of software engineering is that correctness comes >> first, performance and schedule after that. Geoff> I don't believe that statement is correct as an absolute. Geoff> For instance, a product that never ships is *not* better than Geoff> a product that ships with bugs. It is significantly worse. Geoff> Likewise, a product that is guaranteed to produce the correct Geoff> answer, but will take 400 years, is much worse than a product Geoff> that has a 99% chance of producing the correct answer in 10 Geoff> minutes. Depending on the mission, both of those statements are sometimes true and sometimes completely false. Consider safety-critical applications -- flight control, pacemaker firmware, things like that... Other applications aren't quite as stringent, but still, a lot have quality requirements well above those of typical PC applications. Consider a storage server device -- if you're storing data for thousands of users, you have to take correctness VERY seriously if you want to stay in business. Shipping on schedule and then losing customer data will not win you any friends at all. paul Geoff> -- - Geoffrey Keating