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.
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; }
i must bring this issue again as even with 2.7 it is not fixed.
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.
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?
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.