This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]