From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30871 invoked by alias); 27 Nov 2001 21:19:26 -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 30850 invoked from network); 27 Nov 2001 21:19:25 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 21:19:25 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id fARLJPX11758 for ; Tue, 27 Nov 2001 13:19:25 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 27 Nov 2001 13:19:10 -0800 Received: from gourd (gourd.apple.com [17.202.44.182]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id fARLJOh19501; Tue, 27 Nov 2001 13:19:24 -0800 (PST) Date: Mon, 19 Nov 2001 07:56:00 -0000 Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) Cc: gcc@gcc.gnu.org To: "Joseph S. Myers" From: Ziemowit Laski In-Reply-To: Message-Id: <6E5F268F-E37C-11D5-AE62-0030658361CA@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.475) X-SW-Source: 2001-11/txt/msg00881.txt.bz2 On Tuesday, November 27, 2001, at 12:44 , Joseph S. Myers wrote: > On Tue, 27 Nov 2001, Ziemowit Laski wrote: > >> My point (or, perhaps, points) were: >> 1. GCC is used on a variety of real-world platforms >> 2. In that same real world, people have invented tons of >> target-specific extensions to C and C++ to get extra mileage >> out of their particular hardware/OS setup. >> 3. Ergo, we should be able to come up with a 'configure'-based >> mechanism for enabling selected extensions for selected target >> WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS. > > We should never accept dirty extensions on the basis that some other > compilers have them. Target attributes, pragmas and built-in functions And this is, I believe, the main philosophical divide in our little discussion. Yes, I absolutely agree that the extensions (some of them, anyway) are dirty. But: 1. The exist and are used in the real world. 2. C and C++ are not exactly paragons of cleanliness (which, of course, is why they too are used in the real world). If I wanted clean, I'd stick to Ada-95. > provide well-defined ways of using target-specific features without > causing problems for the rest of the compiler. The main thrust of my proposal has been to create a mechanism intended PRECISELY to prevent problems for the rest of the compiler. > > If we accept anything like this feature in GCC, it should be clean and > well-defined. The feature as it is at present - a mess - apparently > comes > from a multi-vendor language model. Where is the specification? What > are See my previous posting for an explanation of why this is not relevant. > If you're distributing diffs (and these would need to cover a lot more > files), just make them available by HTTP and link to them from > extensions.html. No need for them to go in the tree. But is there any harm in INCLUDING them in the tree? > >> 2. At build time, this diff will be used to patch up >> gcc/c-parse.in if needed. > > The established practice is that users building releases do not need to > have Bison installed. And users not needing AltiVec will not need Bison. And those who DO need AltiVec will have the responsibility to install Bison on their system. --Zem -------------------------------------------------------------- Ziemowit Laski Apple Computer, Inc. zlaski@apple.com 2 Infinite Loop, MS 302-4SN +1.408.974.6229 Fax .1344 Cupertino, CA 95014-2085 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ziemowit Laski To: "Joseph S. Myers" Cc: gcc@gcc.gnu.org Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Tue, 27 Nov 2001 13:19:00 -0000 Message-ID: <6E5F268F-E37C-11D5-AE62-0030658361CA@apple.com> References: X-SW-Source: 2001-11/msg01382.html Message-ID: <20011127131900.02BWvHXtuEY3ujHnl957N0uGtaEgM7mK6_aMD7y4T-4@z> On Tuesday, November 27, 2001, at 12:44 , Joseph S. Myers wrote: > On Tue, 27 Nov 2001, Ziemowit Laski wrote: > >> My point (or, perhaps, points) were: >> 1. GCC is used on a variety of real-world platforms >> 2. In that same real world, people have invented tons of >> target-specific extensions to C and C++ to get extra mileage >> out of their particular hardware/OS setup. >> 3. Ergo, we should be able to come up with a 'configure'-based >> mechanism for enabling selected extensions for selected target >> WHILE LEAVING THEM HIDDEN FROM MAINLINE USERS. > > We should never accept dirty extensions on the basis that some other > compilers have them. Target attributes, pragmas and built-in functions And this is, I believe, the main philosophical divide in our little discussion. Yes, I absolutely agree that the extensions (some of them, anyway) are dirty. But: 1. The exist and are used in the real world. 2. C and C++ are not exactly paragons of cleanliness (which, of course, is why they too are used in the real world). If I wanted clean, I'd stick to Ada-95. > provide well-defined ways of using target-specific features without > causing problems for the rest of the compiler. The main thrust of my proposal has been to create a mechanism intended PRECISELY to prevent problems for the rest of the compiler. > > If we accept anything like this feature in GCC, it should be clean and > well-defined. The feature as it is at present - a mess - apparently > comes > from a multi-vendor language model. Where is the specification? What > are See my previous posting for an explanation of why this is not relevant. > If you're distributing diffs (and these would need to cover a lot more > files), just make them available by HTTP and link to them from > extensions.html. No need for them to go in the tree. But is there any harm in INCLUDING them in the tree? > >> 2. At build time, this diff will be used to patch up >> gcc/c-parse.in if needed. > > The established practice is that users building releases do not need to > have Bison installed. And users not needing AltiVec will not need Bison. And those who DO need AltiVec will have the responsibility to install Bison on their system. --Zem -------------------------------------------------------------- Ziemowit Laski Apple Computer, Inc. zlaski@apple.com 2 Infinite Loop, MS 302-4SN +1.408.974.6229 Fax .1344 Cupertino, CA 95014-2085