Re: [RFC] GCC vector extension: binary operators vs. differing signedness

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Dec 12, 2014 at 1:08 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> Richard Biener wrote:
>> On Thu, Dec 11, 2014 at 4:04 PM, Ulrich Weigand <uweigand@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.Weigand@de.ibm.com
>