cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

nou
Exemplar

bug in OpenCL parser depend on locale $LANG

i spend quite some time to debug this bug. parser in OpenCL take only whole part of the decimal number.

so when i wrote 1.23f it will parse as 1.

i must change my locale to en_US.UTF-8 so it parse corectly into 1.23. it seems that parser translate decimal points depending on seted locale and in locale where is decimal separator used comma it fails.

0 Likes
6 Replies

nou,
Sorry for the late response, what is the locale that you are using that is causing the problem?
0 Likes

i am using sk_SK.UTF-8 and tryed also de_DE.UTF-8 so IMHO all locales that use a coma as decimal separator.

there was similiar bug in opencl profiler when it output a coma separated csv files. that was fixed.

this simple kernel should expose it.

__kernel void coma(__global *float number) { number[get_global_id(0)] = 1.234f; }

0 Likes
nou
Exemplar

i must bring this issue again as even with 2.7 it is not fixed.

0 Likes

nou,

I'm sorry, I thought this was fixed. The person I reported it too said they were looking into it but left the company for other opportunities.  I'll make sure someone looks into this and gets it fixed this time.

0 Likes

Nou,

The person who looked into this reported that this is fixed with our internal builds with sk_SK.UTF-8 and also there is a minor error in the kernel('*' should go after float).

Should the kernel use 1.234 or should it use 1,234?

0 Likes

well it should use 1.234. this bug cause that it takes only whole number part so 1.234 is parsed as 1. fractional part of number is dropped.

0 Likes