This is the mail archive of the
mailing list for the GCC project.
Re: Target-specific Front-Ends? (Was: front end changes for altivec)
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Tue, 27 Nov 2001 20:44:13 +0000 (GMT)
- Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec)
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