[Libclc-dev] [PATCH] Fix definition of INFINITY and add NAN/HUGE_VAL[F]

[Aaron Watry]

Yea, I hit send on my last email before I copied in my 3 proposals:

//Option A
#define NAN __builtin_nanf("")
//Option B
#define NAN 0x7fc00000  //non-signalling positive NaN with no payload
//Option C:
#define NAN (INFINITY - INFINITY)

I'd prefer one of B or C, but I'll bow to any compelling arguments otherwise.


if you uncomment the nan test in the test case that was in my last
email, the 2nd two options produce a passing result.  The 1st option [
__builtin_nanf("") ] results in a kernel compilation error with the
following:

Could not build program: CL_BUILD_PROGRAM_FAILURE
Build log for device AMD CEDAR:
 --------
input.cl:48:11: error: passing '__constant char *' to parameter of
type 'const char *' changes address space of pointer
        out[0] = NAN + 1.0f;
                 ^~~
/usr/local/include/clc/float/definitions.h:3:28: note: expanded from macro 'NAN'
#define NAN __builtin_nanf(((__constant char*)""))
                           ^~~~~~~~~~~~~~~~~~~~~~




On Mon, Jun 16, 2014 at 4:50 PM, Jeroen Ketema <j.ketema at imperial.ac.uk> wrote:
>
> Fine with me too.
>
> Regarding NAN. I saw that one of the header files made available by Khronos
> defines it as (INFINITY - INFINITY), would that work for us, or will that
> result in the same compiler warning that Matt pointed out before?
>
> Jeroen
>
> On 16 Jun 2014, at 22:46, Matt Arsenault <Matthew.Arsenault at amd.com> wrote:
>
> On 06/16/2014 02:43 PM, Aaron Watry wrote:
>
> Does anyone mind if I commit the infinify/huge_val[f] change now while
> we continue discussing the NAN change? The infinity/huge_valf changes
> are simple in comparison to the requirements of nan, and I've tested
> that the __builtin_inff() and __builtin_huge_valf() implementations
> work with the attached CL-based test (runnable via piglit).
>
> --Aaron
>
> Sure, I would even commit the broken __builtin_nanf("") for NAN. It's better
> than nothing and it is a problem to fix in clang anyway
>
>
> On Mon, Jun 16, 2014 at 4:33 AM, Jeroen Ketema <j.ketema at imperial.ac.uk>
> wrote:
>
> Hi,
>
> Changing the 2 to a 0 works for me with the NVPTX target:
>
> #define NAN __builtin_nanf((const __attribute__((address_space(0))) char
> *)("”))
>
> However, clang turns the builtin into a call into the C math library, which
> is not what we want…
>
> Jeroen
>
> On 15 Jun 2014, at 23:38, Matt Arsenault <arsenm2 at gmail.com> wrote:
>
>
> On Jun 15, 2014, at 3:33 PM, Jeroen Ketema <j.ketema at imperial.ac.uk> wrote:
>
> Hi Matt,
>
> This needs to be replaced with:
>
> :#define NAN __builtin_nanf((const __attribute__((address_space(2))) char
> *)("”))
>
>
> This won’t work with the NVPTX target. It uses 4 as its constant address
> space and not 2 like r600.
>
> Jeroen
>
>
> It turns out this doesn’t really work either. This is what the OS X headers
> use, and the public version of clang this seems to be broken
>
>
>
>
> _______________________________________________
> Libclc-dev mailing list
> Libclc-dev at pcc.me.uk
> http://www.pcc.me.uk/cgi-bin/mailman/listinfo/libclc-dev
>
>
>
>