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

[Aldy Hernandez <aldyh at redhat dot com>]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

 > Let's try a different tack.  What are we going to do about:

 >  (vector int)(1, 2, 3, 4)

...not going to be supported on fsf sources.  Too ugly.  Nobody can
intellectually reconcile the above nastiness.

I need to implement the above anyhow, but i suppose it will be
provided on additional set of, i suppose, apple+redhat supported
patches, never to be incorporated into gcc.

 > Are we going to try to accept this syntax, or require the C99-like:

 >  (vector int){1, 2, 3, 4}

yes

 > 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.

See the last response by rth.  He came up with a way in which we can
just specify the total vector size in an attribute and determine the
vector mode from the type being modified (int, in this case).  So, we
should be able to cater to both parties-- a more generic approach, and
a few macros to implement altivec syntax, modulo the () initializers.

 > 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?

Yes, but after all this discussion, everything seems to have fallen into
place with the exception of "(1, 2, 3, 4)".  So these will have to be
provided for in external patches.

Aldy