We were missing a declaration of INFINITY in the clc headers and already
had one in gen_convert.py
NOTE: This may not necessarily be the correct value of INFINITY based on
the cl_platform.h headers
Signed-off-by: Aaron Watry <awatry@gmail.com>
We were missing a declaration of INFINITY in the clc headers and already
had one in gen_convert.py
NOTE: This may not necessarily be the correct value of INFINITY based on
the cl_platform.h headers
Signed-off-by: Aaron Watry <awatry@gmail.com>
You probably want to put parentheses around that (just in case).
#define INFINITY (1.0f / 0.0f)
Otherwise, looks good to me. The same should probably be done for NAN, which I think also occurs somewhere already.
Jeroen
You probably want to put parentheses around that (just in case).
#define INFINITY (1.0f / 0.0f)
Otherwise, looks good to me. The same should probably be done for NAN, which I think also occurs somewhere already.
Jeroen
This should be ___builtin_inf/ __builtin_inff
I believe these will have different warning behaviour
You probably want to put parentheses around that (just in case).
#define INFINITY (1.0f / 0.0f)
Otherwise, looks good to me. The same should probably be done for NAN, which I think also occurs somewhere already.
Jeroen
This should be ___builtin_inf/ __builtin_inff
I believe these will have different warning behaviour
Yes, this changes at least -Wfloat-equal
kernel void foo(global int* out, float x)
{
*out = (1.0f / 0.0f) == x; // warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
}
kernel void bar(global int* out, float x)
{
*out = __builtin_inff() == x; // No warning
}
I'll change this to _builtin_inff() and also move the definition of
FLT_NAN/DBL_NAN from the nextafter implementation to definitions.h
(using _builtin_nan[f]), rename them to their proper names and then
send a v2.
--Aaron