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: Per Bothner <per at bothner dot com>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: Ira Ruben <ira at apple dot com>, Stan Shebs <shebs at apple dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 27 Nov 2001 18:27:57 -0800
- Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec)
- References: <755E7B73-E3A4-11D5-AE62-0030658361CA@apple.com>
Ziemowit Laski wrote:
> On Tuesday, November 27, 2001, at 05:36 , Per Bothner wrote:
>> Why would we want to put into our compiler a TARGET-SPECIFIC syntactic
>> extension to handle the rather generic concept of a fixed-size
>> vector? And why
>> would we want to add a configure mechanism to do that?
> Two words: LEGACY CODE.
I know of no GNU or otherwise Free or open-source software that uses
these extensions. So the problem of legacy code is not a GNU problem.
Of course we want gcc to be generally useful, but it cannot be all things
to all people.
People who have code that uses these extensions can use a legacy compiler.
Or they can pay somebody (Apple or Red Hat, for example) to maintain a
compiler that supports the legacy code.
Their legacy code is not our problem - but it will be our problem if we
a kludgy extension into our sources.
> Well, we do have a local tree, and it is a royal pain to maintain in sync
> with the FSF, as Stan can attest. :) In making my proposal, I assumed
> (perhaps wrongly) that a lot of other organizations are in the same
> boat --
> i.e., they have local modifications that they wouldn't mind putting into
> the FSF
I'm sure a lot of companies are in the same boat. That is their problem.
In principle we encourage them to merge in local modifications *if*
they are clean and generally useful. Even more, we encourage people
to think about merging and design and discussing features with the gcc
maintainers *before* they start implementing.