From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7016 invoked by alias); 27 Nov 2001 20:44: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 6868 invoked from network); 27 Nov 2001 20:44:23 -0000 Received: from unknown (HELO navy.csi.cam.ac.uk) (131.111.8.49) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 20:44:23 -0000 Received: from student.cusu.cam.ac.uk ([131.111.179.82] helo=kern.srcf.societies.cam.ac.uk ident=mail) by navy.csi.cam.ac.uk with esmtp (Exim 3.22 #1) id 168p5W-0001D3-00; Tue, 27 Nov 2001 20:44:18 +0000 Received: from jsm28 (helo=localhost) by kern.srcf.societies.cam.ac.uk with local-esmtp (Exim 3.12 #1 (Debian)) id 168p5U-0007qy-00; Tue, 27 Nov 2001 20:44:16 +0000 Date: Mon, 19 Nov 2001 07:13:00 -0000 From: "Joseph S. Myers" X-X-Sender: To: Ziemowit Laski cc: Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-11/txt/msg00874.txt.bz2 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 provide well-defined ways of using target-specific features without causing 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 its Defect Report procedures for dealing with interpretation of ambiguities or defects? For something GCC-specific we can simply discuss it on the gcc list then declare a convenient answer, but if it is meant to be compatible with other compilers there should be a proper system. > How could we go about step 3? I'm sure there are a million ways, > but let me illustrate one possible scenario (for AltiVec): > 1. We create a file called gcc/config/rs6000/c-parse.in.diff > (and something analogous for C++) 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. > 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. -- Joseph S. Myers jsm28@cam.ac.uk From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Joseph S. Myers" To: Ziemowit Laski Cc: Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec) Date: Tue, 27 Nov 2001 12:44:00 -0000 Message-ID: References: X-SW-Source: 2001-11/msg01375.html Message-ID: <20011127124400.krEjvv57ElPZCbMP3lJAZ72dpBCNrUU_kt_bjdfk2hc@z> 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 provide well-defined ways of using target-specific features without causing 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 its Defect Report procedures for dealing with interpretation of ambiguities or defects? For something GCC-specific we can simply discuss it on the gcc list then declare a convenient answer, but if it is meant to be compatible with other compilers there should be a proper system. > How could we go about step 3? I'm sure there are a million ways, > but let me illustrate one possible scenario (for AltiVec): > 1. We create a file called gcc/config/rs6000/c-parse.in.diff > (and something analogous for C++) 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. > 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. -- Joseph S. Myers jsm28@cam.ac.uk