This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Add more altivec builtins
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: Daniel Berlin <dan at cgsoftware dot com>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 5 Dec 2001 19:39:28 +0000 (GMT)
- Subject: Re: [PATCH]: Add more altivec builtins
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).
> > ought to ignore errors in the unused half, which needs the diagnostic
> > machinery from the new C++ parser branch. (I think that diagnostic
> > machinery might be safe to merge onto the mainline now, if you want to do
> > this before 3.1, unlike the new parser itself.)
> 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
The diagnostic machinery is still relevant to ignoring errors in half of
the expression in C.
Joseph S. Myers