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
This is intentional.
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
The patch for this has not been submitted back to TOT clang yet.
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?
Extended Vectors are meant to support OpenCL-ish operations, but not enforce OpenCL error semantics all the time.