<div dir="ltr">As ever my personal views:<br><br><div><div class="gmail_extra">On Tue, Dec 17, 2013 at 5:07 PM, Pekka Jääskeläinen <span dir="ltr"><<a href="mailto:pekka.jaaskelainen@tut.fi" target="_blank">pekka.jaaskelainen@tut.fi</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/17/2013 06:21 PM, Renato Golin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Genuine question: why are there two (more?) variants using LLVM?<br>
</blockquote>
<br></div>
The current conclusion of attempts to merge more of efforts (not<br>
only via the Clang language support) between Clover/libclc and pocl<br>
can be read here:<br>
<a href="http://sourceforge.net/mailarchive/message.php?msg_id=31626357" target="_blank">http://sourceforge.net/<u></u>mailarchive/message.php?msg_<u></u>id=31626357</a><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I may be wrong, but I think this would be a major milestone to get the<br>
"approved technology" stamp.<br>
</blockquote>
<br></div>
I still think the libraries and other supporting infrastructure<br>
is separate from the language support in this question. Isn't this<br>
like saying libstdc++ and libc++ should merge before one can stamp C++ as 1st class? Unfortunately the open source world is not ideal in<br>
this regard either.<br>
<br>
If one needs to execute compiled OpenCL test cases (static checks of<br>
produced bitcode output are not enough) to believe they work,<br>
then I'd rely on a full OpenCL implementation's test suite like<br>
the one of pocl.<br>
<br>
For the specification issue. If the specs leaves some things open/vague,<br>
it's the problem of the specs? It's an implementation dependent detail<br>
then? OpenCL C is derived from C99 and adds some features which one<br>
can state that are supported or not, in a language status<br>
table like there is for the C++ features. Ultimately it's the<br>
Khronos' conformance test that says whether an implementation is<br>
conformant or not. Hopefully some day that will also happen for<br>
an open source implementation.<br></blockquote><div><br></div><div>Note that as Pekka implies above, the OpenCL specifications (for the various versions) are 1 document that does both:<br><br></div><div>1. Defines the OpenCL "actual language" elements.<br>
</div><div>2. Defines the names and behaviours of various pieces of the runtime support.<br><br></div><div>The impression I have is that most of issues of some ambiguity in the specification relate to various pieces of the<br>
</div><div>runtime. If the question is whether the "clang front-end" processes OpenCL C correctly then ambiguities related to the<br></div><div>runtime are less significant. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I agree with David that the test suite in the Clang side should<br>
invclude also (more?) negative test cases for the language<br>
errors/diagnostics for things that are not allowed in OpenCL C<br>
(but might be in C99).<br></blockquote></div><br></div><div class="gmail_extra">Well, not just differences between C and OpenCL but also ensure the front-end is being strict enough<br>about allowing OpenCL constructs only where the standard allows them.<br>
</div><div class="gmail_extra"><br>-- <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>