<div dir="ltr">Speaking in a personal capacity,<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 17, 2013 at 4:21 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On 17 December 2013 15:16, Pekka Jääskeläinen <span dir="ltr"><<a href="mailto:pekka.jaaskelainen@tut.fi" target="_blank">pekka.jaaskelainen@tut.fi</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">AFAIK Clover, like pocl, uses (or at least tries to) the upstream Clang<br>


for an OpenCL C frontend. There are not many unimplemented features of<br>
the OpenCL 1.2 language in Clang that I know of anymore.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In any case, I do not understand why OpenCL C is treated as a kind of<br>

a 2nd class language in Clang now, at least I get that feeling of it.<br></blockquote><div></div></div></div><br></div><div class="gmail_extra">There are no guarantees that it will work on every release.</div><div class="gmail_extra">

<br></div><div class="gmail_extra">The ARM back-end used to be second-class because even though there were some buildbots, they would randomly fail, the test-suite wasn't passing and not many people outside Apple would add code to it. </div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Since a few years ago, ARM got interest, and this year Linaro, Qualcomm and others joined the crew and we have this amazing group of developers adding features and fixing bugs, we have lots of buildbots and the test-suite passes green every time, and every release we bootstrap, test, benchmark, and make binary releases. It's a lot of work to be able to stamp "first-class" on something, but it's worth it.</div>

<div class="gmail_extra"><br></div></div></blockquote><div>I'll note that all those issues primarily of big import to a back-end (or possibly a complete compiler). The situation with common, open-source OpenCL is it is primarily in terms of modifications to the clang front-end to be able to generate fully accurate AST's for OpenCL and ot issue correct and informative diagnostics. It would be useful to see what sort of consensus the community arises as to what ought to be being done for this case: for a front end I suspect it's going to be generating a lot more test cases to ensure features can only be used where the OpenCL specifications allow them to be.<br>
</div><br clear="all"></div>-- <br><div>cheers, dave tweed__________________________</div><div>high-performance computing and machine vision expert: <a href="mailto:david.tweed@gmail.com" target="_blank">david.tweed@gmail.com</a></div>
<div>"while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot</div><div> </div>
</div></div></div>