This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Add more altivec builtins
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: Daniel Berlin <dan at cgsoftware dot com>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: 05 Dec 2001 11:49:53 -0800
- Subject: Re: [PATCH]: Add more altivec builtins
- References: <Pine.LNX.email@example.com>
On Wed, 2001-12-05 at 11:39, Joseph S. Myers wrote:
> On 5 Dec 2001, Aldy Hernandez wrote:
> > > Also the point that the companion built-in function __builtin_choose_expr
> > why do we need this companion function? is it absolutely necessary?
> > can't we achieve the same functionality with stmt expressions?
> Statement expressions are irrelevant; their type is just the type of the
> expression of the expression statement that is the last statement in them.
> Your problem is to arrange for the return value to be of the correct type,
> and to call the right function when calling the wrong function would be an
> error (for example, if passing vector float arguments to a function
> expecting vector int ones is an error, such a call cannot be present
> anywhere in the expression, even in a conditioned out (if (0)) part,
> without special treatment to ignore such errors).
ahh, i see.
> > i'm not planning on doing a c++ version of it, rth suggested this
> > wasn't necessary because c++ already has real overloading and templates,
> > so we don't need it for c++. i will be provididng a c++ variant of
> > altivec.h
> The diagnostic machinery is still relevant to ignoring errors in half of
> the expression in C.
ok, i see. it would be nice, not absolutely necessary.
Aldy Hernandez E-mail: firstname.lastname@example.org
Red Hat, Inc.