[cfe-dev] OpenCL C

[Richard Smith]

On Tue, Dec 17, 2013 at 9:02 AM, Erik Schnetter <schnetter at gmail.com> wrote:

> On Dec 17, 2013, at 11:44 , Renato Golin <renato.golin at linaro.org> wrote:
>
> > On 17 December 2013 16:35, David Tweed <david.tweed at gmail.com> wrote:
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > But without any of these, I can't see how can we say something is
> "supported".
>
> OpenCL C is a language, same as C or C++ or Objective C. There is a
> well-defined standard


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).


> I think OpenCL C is ready to be a first-class language in clang.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131217/7930633b/attachment.html>