On Fri, Dec 12, 2014 at 1:08 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: > Richard Biener wrote: >> On Thu, Dec 11, 2014 at 4:04 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: >> > However, if we make that change, there will be some cases that regress: the >> > problem is that an expression "x + y" has *one* result type, and some >> > things >> > you do with the result will require that type to match precisely (including >> > signedness). So *any* change that affects what that result type is will >> > regress some code that happened to rely on the precise result type ... >> >> True, but IMHO that's still better. You may want to check the openCL spec >> which we tried to follow losely as to what we allow. >> >> So again, implementing your A is ok with me. > > Well, the openCL spec says that operations between signed and unsigned > vectors are simply prohibited (both openCL 1.2 and openCL 2.0 agree on > this, and it matches the behavior of my old openCL compiler ...): > > 6.1.2 Implicit Conversions: > Implicit conversions between built-in vector data types are disallowed. > > 6.2.6 Usual Arithmetic Conversions: > If the operands are of more than one vector type, then an error shall > occur. Implicit conversions between vector types are not permitted, > per section 6.2.1. > > 6.3 Operators: > > All arithmetic operators return result of the same built-in type > (integer or floating-point) as the type of the operands, after operand > type conversion. After conversion, the following cases are valid: > - The two operands are scalars. [...] > - One operand is a scalar, and the other is a vector. [...] > - The two operands are vectors of the same type. [...] > All other cases of implicit conversions are illegal. > > xlcl error message: > 1506-068 (S) Operation between types "__private uint4" and "__private int4" > is not allowed.
The question is what the fallout is if we reject this by default (I suppose we accept it with -flax-vector-conversions). I'm ok with following OpenCL as well, that is either solution that makes behavior consistent between C and C++. Richard. > Bye, > Ulrich > > -- > Dr. Ulrich Weigand > GNU/Linux compilers and toolchain > ulrich.weig...@de.ibm.com >
