[cfe-dev] OpenCL C

Pekka Jääskeläinen pekka.jaaskelainen at tut.fi
Tue Dec 17 09:07:45 PST 2013


On 12/17/2013 06:21 PM, Renato Golin wrote:
> Genuine question: why are there two (more?) variants using LLVM?

The current conclusion of attempts to merge more of efforts (not
only via the Clang language support) between Clover/libclc and pocl
can be read here:
http://sourceforge.net/mailarchive/message.php?msg_id=31626357

> I may be wrong, but I think this would be a major milestone to get the
> "approved technology" stamp.

I still think the libraries and other supporting infrastructure
is separate from the language support in this question. Isn't this
like saying libstdc++ and libc++ should merge before one can stamp C++ 
as 1st class? Unfortunately the open source world is not ideal in
this regard either.

If one needs to execute compiled OpenCL test cases (static checks of
produced bitcode output are not enough) to believe they work,
then I'd rely on a full OpenCL implementation's test suite like
the one of pocl.

For the specification issue. If the specs leaves some things open/vague,
it's the problem of the specs? It's an implementation dependent detail
then? OpenCL C is derived from C99 and adds some features which one
can state that are supported or not, in a language status
table like there is for the C++ features. Ultimately it's the
Khronos' conformance test that says whether an implementation is
conformant or not. Hopefully some day that will also happen for
an open source implementation.

I agree with David that the test suite in the Clang side should
invclude also (more?) negative test cases for the language
errors/diagnostics for things that are not allowed in OpenCL C
(but might be in C99).

-- 
--Pekka



More information about the cfe-dev mailing list