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

[Matt Arsenault]

On 06/16/2014 02:50 PM, Jeroen Ketema 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

That gives me the same warning

>
> On 16 Jun 2014, at 22:46, Matt Arsenault <Matthew.Arsenault at amd.com 
> <mailto: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
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libclc-dev/attachments/20140616/c8d75206/attachment.html>