[cfe-dev] [PATCH] OpenCL 1.2 storage class specifiers and errors

[Tanya Lattner]

On Jun 14, 2012, at 3:26 PM, Anton Lokhmotov <Anton.Lokhmotov at arm.com> wrote:

> Tanya Lattner wrote:
> 
>> Yes, but mainline Clang does not fully support OpenCL 1.0 or later. I
>> am not saying that it should never be added, but I am not the one who
>> has the time to add it at this point. If someone wants to go back and
>> go through all the OpenCL changes and clarify which ones are 1.0, 1.1,
>> 1.2 then that can be done in a separate step. I would rather not have
>> my patches delayed just because we now have decided to force people to
>> clarify what is 1.0, 1.1 and 1.2.
> 
> Oh no, this would be extremely unpragmatic.  I specifically said that we
> should not try to distinguish between support for OpenCL 1.0 and OpenCL 1.1,
> as the former is pretty much deprecated.  (I hesitate to say the same about
> the latter, as I am still polishing it :).)
> 
> Given that your new patches are first supporting OpenCL 1.2, I think now is
> the right time to reflect on this problem to avoid going through the painful
> process of reclassification in the future.
> 
> Guy Benyei wrote:
>> Anyhow, I'd prefer to define the OpenCL version to be represented as an
>> unsigned integer, similarly to what the OpenCL spec defines about the
>> version macros: OpenCL 1.1 should be represented as 110, 1.2 as 120, etc..
>> 
>> This is useful, since features are supported beginning from some OpenCL
>> version, so the right condition should be something like:
>> 
>> // OpenCL v1.2 s6.8: The static storage-class specifier can only
>> // be used for non-kernel functions.
>> if (getLangOpts().OpenCL_Version >= 120 && SC == SC_Static &&
> 
> This sounds good.  Even if a feature appears in one version and disappears
> in a subsequent one, one can always use ranges (e.g. V >= 110 && < V <=
> 120).
> 
> The question is which OpenCL version should the existing
> getLangOpts().OpenCL correspond to by default.  Since today no OpenCL 1.2
> features are on ToT, we can declare 1.1 as default and 1.2  features should
> be added in the way you propose.  At some amicably agreed point in the
> future we can switch the default, by marking all OpenCL 1.1 specific
> restrictions as such.
> 
> Guy, do you think you could prepare a patch that adds OpenCL_Version to
> LangOpts?  Then Tanya would be able to update her patches to use it.
> 

Alright, since this proved to take 5 minutes (go Clang), I just did it because I don't want to be held up since I have a bunch of stuff I'm trying to push out.

Here is the patch, please review:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenCLVersion.patch
Type: application/octet-stream
Size: 2081 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120614/93e80277/attachment.obj>
-------------- next part --------------


-Tanya


> Cheers,
> Anton.
> 
> 
>