<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 17, 2013 at 9:02 AM, Erik Schnetter <span dir="ltr"><<a href="mailto:schnetter@gmail.com" target="_blank">schnetter@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Dec 17, 2013, at 11:44 , Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br>

<br>
> On 17 December 2013 16:35, David Tweed <<a href="mailto:david.tweed@gmail.com">david.tweed@gmail.com</a>> wrote:<br>
> 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>

><br>
> AFAIK OpenCL doesn't have a concrete specification, or the one you have is not concrete enough in some places, and too concrete in others.<br>
><br>
> You can create perfectly valid Dwarf that no debugger in the world can digest. You can create perfectly valid ELF objects that won't link with others. You can parse C++ into a parfectly valid AST, but if you can't build proper (target-specific) IR from it, it's useless.<br>

><br>
> For instance, if there is an official (Kronos-certified) parser that tells you whether a piece of OpenCL IR/AST conforms to the standard, that's a starter. If there is an emulator that executes OpenCL on the CPU as if it were some GPU, that's better. If there is a standard CPU implementation that will be actually used in production (like the Intel one), that's a lot better.<br>

><br>
> But without any of these, I can't see how can we say something is "supported".<br>
<br>
</div></div>OpenCL C is a language, same as C or C++ or Objective C. There is a well-defined standard</blockquote><div><br></div><div>I disagree. The OpenCL standard is very imprecise, to the point where we frequently *cannot tell* whether a proposed patch to implement an OpenCL feature is correct by reference to the standard. As far as I know, we don't have any active contributing members of the Clang community who are sufficiently closely linked to the OpenCL standardization process to answer our questions (and maybe get the standard fixed in the process).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think OpenCL C is ready to be a first-class language in clang.<br></blockquote><div><br></div><div>We need people to step forward who are willing and able to divine the intent of the OpenCL standard, determine what's missing, implement the missing features, and support this configuration in the long term.</div>
</div></div></div>