This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Target-specific Front-Ends? (Was: front end changes foraltivec)
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Stan Shebs <shebs at apple dot com>, Per Bothner <per at bothner dot com>
- Cc: Ziemowit Laski <zlaski at apple dot com>, Ira Ruben <ira at apple dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 27 Nov 2001 20:34:52 -0800
- Subject: Re: Target-specific Front-Ends? (Was: front end changes foraltivec)
>> Let me answer for you: We don't.
>
> Who's this "we" you're referring to?
>
> Zem's proposal does challenge GCC orthodoxy, but in the past
> you've been the one to question the rules imposed by other people.
Let's be very careful to keep this polite. It's right on the edge
at the moment; everyone is getting tense. No SHOUTING, please; and
let's not try to shut anyone up either.
Let's try a different tack. What are we going to do about:
(vector int)(1, 2, 3, 4)
Are we going to try to accept this syntax, or require the C99-like:
(vector int){1, 2, 3, 4}
If the latter, then we have a source-incompatible change. Once we
do that, all Altivec users have to change their code, and changing
"vector int" into "__attribute__((vector(4)) int" is not a whole
lot worse.
I think the fundamental question is not what to do about vector;
it's whether or not we're going to try to implement the Altivec
syntax or just its semantics.
It seems that most people would prefer the latter, but that the folks
at Apple would prefer the former. Apple would like to stop having
to merge the Altivec patches, and they do not seem to believe that
users will be willing to change their code. Is that right?
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com