Re: Target-specific Front-Ends? (Was: front end changes for altivec)

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

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