This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


> Bye,
> Ulrich
> --
>   Dr. Ulrich Weigand
>   GNU/Linux compilers and toolchain

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]