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