[llvm-dev] [OpenCL] Implicit arithmetic conversion of INT_MIN to int vector type

[Stephen Canon via llvm-dev]

> On Sep 10, 2015, at 6:30 AM, Pflanzer, Moritz via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Finally, for clang in C mode (-x c) also both version work and no error is produced. I attached a test case in which a summarised all my findings. The behaviour I observed should be reproducible with
> 
> $ clang -x cl -S -emit-llvm -O0 -o - vector_conversion.c
> $ clang -x c -S -emit-llvm -O0 -o - vector_conversion.c
> 
> I would be interested in your thoughts about this behaviour, whether it is correct that -2147483648 is represented as long or whether the behaviour can be considered as bug in the OpenCL frontend of Clang. (Another possibility would be that the representation as long is correct but it is nevertheless a bug that the subtraction is not possible.)

To address the difference between C and OpenCL:

In OpenCL, we’re constrained by 6.2.6 "An error shall occur if any scalar operand has greater rank than the type of the vector element.”

For C, we deliberately adopted a more relaxed requirement, because the OpenCL rules are, quite frankly, infuriating in real-world vector code when dealing with integer types.

Your actual question: OpenCL C follows the C standard w.r.t. integer literals, so -2147483648 has type long and thus cannot be implicitly converted to intN (due to the rule I quoted above).  Both C and CL are behaving correctly here; as you have already surmised, the bug is in the definition of INT_MIN.

– Steve