[cfe-dev] Giving consistent semantics to extended vectors

[Anton Lokhmotov]

Hello,

I've been investigating how Clang interprets operations on extended vectors
[those declared with __attribute__((ext_vector_type(n))], in particular with
respect to the OpenCL semantics, since
http://clang.llvm.org/docs/LanguageExtensions.html#vectors implies that
extended vectors have some support for OpenCL constructs.

My conclusion is that Clang's behaviour with respect to OpenCL considerably
varies from producing wrong diagnostics to accepting invalid statements and
rejecting valid statements to silently producing wrong LLVM code.  Couple of
examples (all vector types have obvious definitions):

uchar4 vu = (uchar4) true;  
	// results in: (0x01, 0x01, 0x01, 0x01)
	// must be: (0xff, 0xff, 0xff, 0xff)

int4 vu = (uint4) vi; // disallowed in OpenCL, accepted by Clang

uchar2 vuca; char2 vsca;
char2 vscc = vsca < vuca;
	// disallowed in OpenCL, rejected by Clang:
	// error: can't convert between vector values of different size
('uchar2' and 'char2')

int4 via, vib, vic;
vic = (via == vib ? via : vib);	// allowed in OpenCL, rejected by Clang:
	// error: used type 'int4' where arithmetic or pointer type is
required

short2 vs, vr; int i;
vr = vs < i;
	// down-conversion and vector widening: disallowed by OpenCL,
rejected by Clang:
	// error: can't convert between vector values of different size
('short2' and 'int')
	// (clearly, the error message could be more helpful)

My question is whether it anyone has objections to making statements
involving extended vectors to have by default semantics consistent with
OpenCL or only have the OpenCL semantics when the LangOpts flag is enabled?

Anton L.