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]

Re: Vector Extensions in GCC


"Joseph S. Myers" wrote:
> 
> On Wed, 11 Jul 2001, Stan Shebs wrote:
> 
> > in 3.x, and it looks to me like we need to start over (just as well,
> > since Motorola has never assigned their copyright).
> 
> Why were copyright assignments a problem for this (given that there is an
> old assignment from Motorola on file for other changes
> 
> GCC     Motorola, Computer Group Core Technologies and Systems  1993-08-19
> Assigns all changes by Motorola which are incorporated into the FSF's
> source base (m68k, m88k support).
> 
> )?

At least going by the description, this is not a "future changes"
assignment, so it would cover only things that they had done up to
that point, which wouldn't include AltiVec work.  (Companies are
often reluctant to sign future changes assignments, their lawyers
worry about giving away IP before it's even been written.)

> > Are overloaded builtins a good idea?  If so, do they need any
> > special support from generic code?
> 
> Overloaded builtins are desirable in order to implement <tgmath.h> in a
> sane way - see the projects list.  The C front end would need to carry out
> overload resolution on builtin calls at a sufficiently early stage, before
> it tries to convert argument types or work out what the type of the
> expression calling the builtin is.  Once that support is in,
> target-dependent overloaded builtins are probably fairly harmless.

Aha - in fact I was just looking at tgmath.h, in connection with
__builtin_classify_type, perhaps I should run the risk of brain
strain and try to do the generic overloaded builtins first, get
rid of the bogus builtin and improve tgmath.h at the same time...

> > If vector constants are a bad idea, what should programmers do
> > instead?
> 
> The C99 compound literal syntax would be far preferable to the syntax with
> parentheses you give an example of.  (That is, (vector float) {1.0, 2.0,
> 3.0, 4.0} instead of (vector float) (1.0, 2.0, 3.0, 4.0).)

Interesting, worth taking a look at.  Thanks for the idea!

Stan


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