[cfe-dev] On which option should vector operator ? : depend?

[Douglas Gregor]

On Sep 29, 2010, at 12:35 PM, Daniel Dunbar wrote:

> On Wed, Sep 29, 2010 at 11:23 AM, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>> On Sep 29, 2010, at 11:08 AM, Sebastian Redl wrote:
>> 
>>> 
>>> On Sep 29, 2010, at 11:01 AM, Daniel Dunbar wrote:
>>> 
>>>> On Wed, Sep 29, 2010 at 10:41 AM, Sebastian Redl
>>>> <sebastian.redl at getdesigned.at> wrote:
>>>>> It seems weird to me too, but I think the question here is not whether to have it - IIUC OpenCL demands it - but whether it makes sense to make it work conditionally only for some language flags. And IMO, if you have ?: mean vector select in one dialect, you might as well make it work in all of them.
>>>> 
>>>> Why? OpenCL is a different language in many ways.
>>> 
>>> AltiVec vector support isn't.
>> 
>> For AltiVec support, we have precedent to follow: what does GCC do? We need to do the same.
>> 
>> Now, Clang's ext_vector_type is a specific vector type that Clang added for OpenCL. It seems reasonable that it would have OpenCL's semantics, regardless of dialect. For example, we permit the OpenCL "vec.xyzw" syntax for ext_vector_type vectors in all dialects.
> 
> Yes, but that syntax has no (sensical) precedent in C, so programmers
> aren't likely to confuse it with "what C would normally do", at least
> in code that compiles.

I think that's a wonderful argument against OpenCL's abuse of the ? : notation to mean vector selection. But, OpenCL made that decision, so our only decision is whether this syntax applies to Clang's extended vectors (the purpose of which is to support OpenCL) or to Clang when in OpenCL mode. We have precedent for the format.

Note that there's no conversion from a vector type to bool, so 

	vec? vec1 : vec2

is currently ill-formed. So, while having that expression turn into a select might confuse a C programmer, at least we're not changing the semantics of existing, well-formed code.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100929/4b9ba98b/attachment.html>