From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27859 invoked by alias); 17 Jan 2004 15:26:40 -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 27852 invoked from network); 17 Jan 2004 15:26:39 -0000 Received: from unknown (HELO Cantor.suse.de) (195.135.220.2) by sources.redhat.com with SMTP; 17 Jan 2004 15:26:39 -0000 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id E3A9B19FC73B; Sat, 17 Jan 2004 16:23:13 +0100 (CET) Received: from aj by arthur.inka.de with local (Exim 4.22) id 1Ahs4n-0005tL-6Z; Sat, 17 Jan 2004 16:09:29 +0100 To: Steven Bosscher Cc: kenner@vlsi1.ultra.nyu.edu (Richard Kenner), dje@watson.ibm.com, gcc@gcc.gnu.org Subject: Re: [RFC] Contributing tree-ssa to mainline References: <10401171337.AA17355@vlsi1.ultra.nyu.edu> <200401171503.12350.s.bosscher@student.tudelft.nl> From: Andreas Jaeger Date: Sat, 17 Jan 2004 15:26:00 -0000 In-Reply-To: <200401171503.12350.s.bosscher@student.tudelft.nl> (Steven Bosscher's message of "Sat, 17 Jan 2004 15:03:12 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SW-Source: 2004-01/txt/msg01065.txt.bz2 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 1938 Steven Bosscher writes: > On Saturday 17 January 2004 14:37, Richard Kenner wrote: >> If we want to develop a GCC 3.5 release without Tree-SSA, then we >> should have specific, non-SSA feature goals that we want to >> accomplish. Otherwise, what is the benefit of GCC 3.5 over addition= al >> point releases of GCC 3.4 stable branch? >> >> I don't understand your point. Since GCC is a volunteer project, there = is >> no practical way of forming such "goals" or schedules. We presume, unle= ss >> there's evidence to the contrary that people are going to be working on >> improvements to GCC into the future. > > That is what everyone is saying every time somebody suggests we should > have goals for the next release. > > Result: everyone just starts hacking without any form of plan, and we > end up with lots of half-finished efforts. > > It is OK to say: "For this release our goals are...". Get a good number > of people (volunteers) to agree on that, and you can make those goals. > Do nothing, and nothing happens. I agree. Let's write down which goals we want to have - and strive to get them done. If we figure out after some time that some goals are not realistic in our timeframe, then move them to the next release (so, we always have two lists: one for current release and one for the release afterwards). But having some goals that are understood, helps to concentrate effort and gives developers some ideas what they should do. For example some goals might be: For 3.5: - variable tracking - Tree-SSA with: * at least same performance as 3.4 * published interfaces between frontends and middle-end - Fortran95 front-end - ... After 3.6: - vectorization - ... Andreas --=20 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SuSE Linux AG, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GPG fingerprint =3D 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 --=-=-= Content-Type: application/pgp-signature Content-length: 188 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQBACVApOJpWPMJyoSYRAuSCAJ9IBzaEF5zDOZUAafnxX3BMVJf8zgCff06S pCkAdCp2Lh3jL48Tc0bKX/Y= =USue -----END PGP SIGNATURE----- --=-=-=--