Current definition of INT_MIN causes problems

Runtimes OpenCL
1

Hello,

I found out that the current definition of INT_MIN as

#define INT_MIN (-2147483648)

can cause problems because this number seems to be represented as long in the Clang compiler which leads to conversion failures. I posted a message with some more details to the llvm-dev mailing list to ask about the behaviour (http://lists.llvm.org/pipermail/llvm-dev/2015-September/090278.html).

Nevertheless, the problem could be prevented if the definition is changed to

#define INT_MIN (-2147483647 - 1)

which is represented as int. This is also the definition that the OpenCL C 1.1 standard suggests (§6.11.3).

Is there a particular reason why this definition is not used or do you have any concerns about changing it?

Regards,

Moritz

2

Hello,

I found out that the current definition of INT_MIN as

#define INT_MIN (-2147483648)

can cause problems because this number seems to be represented as long in the Clang compiler which leads to conversion failures. I posted a message with some more details to the llvm-dev mailing list to ask about the behaviour (http://lists.llvm.org/pipermail/llvm-dev/2015-September/090278.html).

Nevertheless, the problem could be prevented if the definition is changed to

#define INT_MIN (-2147483647 - 1)

which is represented as int. This is also the definition that the OpenCL C 1.1 standard suggests (§6.11.3).

Is there a particular reason why this definition is not used or do you have any concerns about changing it?

Sounds reasonable to me.

I’ll try to check the other definitions later and see if I have time to prep a patch/tests.

–Aaron