<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div>Fine with me too.</div><div><br></div><div>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?</div><div><br></div><div>Jeroen</div><br><div><div>On 16 Jun 2014, at 22:46, Matt Arsenault <<a href="mailto:Matthew.Arsenault@amd.com">Matthew.Arsenault@amd.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="moz-cite-prefix">On 06/16/2014 02:43 PM, Aaron Watry wrote:<br></div><blockquote cite="mid:CAM+GqJYP+pnWK6Xjbk9yN1Z0m3CgCzJbZvTSCD1ZCjGQ4vbciQ@mail.gmail.com" type="cite"><pre wrap="">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</pre></blockquote>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<br><br><br><blockquote cite="mid:CAM+GqJYP+pnWK6Xjbk9yN1Z0m3CgCzJbZvTSCD1ZCjGQ4vbciQ@mail.gmail.com" type="cite"><pre wrap="">On Mon, Jun 16, 2014 at 4:33 AM, Jeroen Ketema <a class="moz-txt-link-rfc2396E" href="mailto:j.ketema@imperial.ac.uk"><j.ketema@imperial.ac.uk></a> wrote:
</pre><blockquote type="cite"><pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:arsenm2@gmail.com"><arsenm2@gmail.com></a> wrote:
On Jun 15, 2014, at 3:33 PM, Jeroen Ketema <a class="moz-txt-link-rfc2396E" href="mailto:j.ketema@imperial.ac.uk"><j.ketema@imperial.ac.uk></a> 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
</pre><br><fieldset class="mimeAttachmentHeader"></fieldset><br><pre wrap="">_______________________________________________
Libclc-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libclc-dev@pcc.me.uk">Libclc-dev@pcc.me.uk</a>
<a class="moz-txt-link-freetext" href="http://www.pcc.me.uk/cgi-bin/mailman/listinfo/libclc-dev">http://www.pcc.me.uk/cgi-bin/mailman/listinfo/libclc-dev</a>
</pre></blockquote></blockquote><br></div><br class="Apple-interchange-newline"></blockquote></div><br></body></html>