[cfe-dev] OpenCL C

[David Tweed]

As ever my personal views:

On Tue, Dec 17, 2013 at 5:07 PM, Pekka Jääskeläinen <
pekka.jaaskelainen at tut.fi> wrote:

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

Note that as Pekka implies above, the OpenCL specifications (for the
various versions) are 1 document that does both:

1. Defines the OpenCL "actual language" elements.
2. Defines the names and behaviours of various pieces of the runtime
support.

The impression I have is that most of issues of some ambiguity in the
specification relate to various pieces of the
runtime. If the question is whether the "clang front-end" processes OpenCL
C correctly then ambiguities related to the
runtime are less significant.


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

Well, not just differences between C and OpenCL but also ensure the
front-end is being strict enough
about allowing OpenCL constructs only where the standard allows them.

-- 
cheers, dave tweed__________________________
high-performance computing and machine vision expert: david.tweed at gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131217/82d1f749/attachment.html>