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

[Ziemowit Laski <zlaski at apple dot com>]

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