From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11839 invoked by alias); 4 Aug 2003 05:46:34 -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 11832 invoked from network); 4 Aug 2003 05:46:33 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.73.237.138) by sources.redhat.com with SMTP; 4 Aug 2003 05:46:33 -0000 Received: (qmail 26050 invoked from network); 4 Aug 2003 05:44:46 -0000 Received: from egil.codesourcery.com (HELO taltos.codesourcery.com) (zack@66.92.14.122) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 4 Aug 2003 05:44:46 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Sun, 3 Aug 2003 22:46:31 -0700 From: "Zack Weinberg" To: obrien@FreeBSD.org Cc: Aaron Lehmann , Steven Bosscher , gcc@gcc.gnu.org Subject: Re: GCC References: <1059633859.3637.8.camel@steven.lr-s.tudelft.nl> <20030731064707.GA20389@vitelus.com> <20030804044232.GA33831@dragon.nuxi.com> Date: Mon, 04 Aug 2003 07:42:00 -0000 In-Reply-To: <20030804044232.GA33831@dragon.nuxi.com> (David O'Brien's message of "Sun, 3 Aug 2003 21:42:32 -0700") Message-ID: <87d6fmt1oo.fsf@egil.codesourcery.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-08/txt/msg00099.txt.bz2 "David O'Brien" writes: > I think a much more accurate description would be Zack's "A Maintenance > Programmer's View of GCC" from the Ottawa GCC Summit. My last patch > trying to add a "GCC_OPTIONS" environmental variable was for AMD and some > very large ISV's benefit. Didn't go in, and not for copyright assignment > issues. That's not a great example. There was nothing technically wrong with your patch; rather, people have convincing arguments that we don't want that feature. This is not normally going to happen to target-specific optimization patches. I would suggest the SPE and Altivec patchsets as better examples of the problems in this area. Those are features that no one objects to in the abstract -- support for two different sets of vector instructions, and the related intrinsics -- but Aldy had to do tremendous amounts of work to get them to the point where they were acceptable. Part of the problem is that the backend API is a mess; that's the stuff I talked about in my paper. Work is ongoing to clean that up. I think we'll be in much better shape in a few years. But the other part of the problem is that the features were designed without consulting with people who knew what the C and C++ standards have to say in this area, and so (for example) the original Altivec patches had vector-initializer syntax that was considered unacceptable, which makes GCC 3.x's Altivec incompatible with the original Motorola compilers. The only way that situation can improve is if GCC maintainers are brought on board in the design stages of such projects, and can point out the problems before they become entrenched. zw p.s. I wonder if the GCC_OPTIONS patch would be more acceptable if it were processed by the driver, so that the additional options showed up in -v output.