Re: Altivec discussion summary, future direction

[Aldy Hernandez <aldyh at redhat dot com>]

> > (1) Adds a '-faltivec' switch (for Darwin targets only), which is
> > similar to '-maltivec' except that the <altivec.h> header gets pulled
> > in automatically as well.
> 
> > (3) Adds support for 'vector pixel' and 'vector bool ...' types as
> > _distinct_ from 'vector unsigned ...' (This was missing from
> > AldyVec), and adds canonical name-mangling for the AltiVec types.
> 
> > (5) Adds support for the -W[no-]altivec-long-deprecated flag (for
> > Darwin targets only) to optionally suppress warnings about uses of
> > 'vector long ...'  types.
> 
> 1. Items from (1), (3), and (5), which didn't get significant
>    commentary.  I think this patch, as a standalone item, will get
>    some discussion.  I'm hoping that this patch will be almost all
>    rs6000-specific or Darwin-specific, and it should be able to go
>    into 3.5 (maybe even 3.4 if it seems safe---the type part of the
>    patch is a genuine bug fix, Aldy's work was supposed to comply with
>    the PIM).

FWIW, I agree with Geoff's future direction comments.  1, 3, and 5
I'm ok with.  #1, I'm not particularly fond of, but I won't object.
Everything else (comma initializers, and context sensitive keywords)
I don't like at all.

WRT the comma initializer discussion, it was my understanding that Motorola
had added the curly brace initializer to the PIM, in addition to the
brain dead comma initializer scheme-- and that other compiler vendors
were moving towards the curly brace implementation.  So if anything,
IBM (the latest compiler vendor to support AltiVec) should be pestered to 
support the curly brace implementation, and help us all move along to sanity.

AldyVec
help us all out of this 

Cheers.
Aldy