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

Anton Lokhmotov Anton.Lokhmotov at arm.com
Thu Jun 14 15:26:39 PDT 2012

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

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.


More information about the cfe-dev mailing list