As a C programmer, I find the behaviour of ext_vector conversions

surprising.

typedef float float4 __attribute__((ext_vector_type(4)));

typedef int int4 __attribute__((ext_vector_type(4)));

float4 f(float4 a, int4 b)

{

return a + b;

}

define <4 x float> @f(<4 x float> %a, <4 x i32> %b) nounwind uwtable readnone {

entry:

%0 = bitcast <4 x i32> %b to <4 x float>

%add = fadd <4 x float> %0, %a

ret <4 x float> %add

}

I've looked, but not found the story behind this. Would there be

objections to having conversions, like other ext_vector operations,

perform the corresponding scalar operation elementwise instead?

I am no an cfe vector expr developer, so I also don't know the story behind this, but I guess this is a bug of cfe.

To add an information a bit, the code handles float4 + int4 arithmetic with conversion-free casting, whereas OpenCL keenel and gcc vector extension(and possibly AltiVec extension) does not allow float4 + int4 expression.

Also note, arithmetic operations and type casting is not C compatible for vector variables(see OpenCL spec for example)

Wei Pan pointed me to <http://gcc.gnu.org/ml/gcc/2006-10/msg00242.html>,

which explains that the surprising silent bitcast originates with the

AltiVec programming model.

Excluding the LangOptions.AltiVec case, and any others with special

rules, would there be objections to having ext_vector conversions

perform the 'natural' elementwise conversion?