[cfe-dev] OpenCL parsing / type support

[Chris Lattner]

On Mar 11, 2010, at 3:17 AM, Anton Lokhmotov wrote:

> I am also looking into OpenCL support in Clang, and am learning quite a few
> of hacks Chris and Arnaud are referring to.  It would be good, however, to
> implement OpenCL features properly, so that setting LangOpts.OpenCL=1 would
> just work.  I suggest we make a conscious community-wide effort here so that
> various implementations do not reinvent the wheel. (So Arnaud it would be
> great if you could contribute to Clang head your patch for address space and
> kernel attributes!)

I'm fine with improving infrastructure to support this, but there is no reason to add first class language support for things like __kernel.  It just makes the compiler more complex for no reason.  If you're interested in driving this, a better thing to focus on would be to provide an implementation of the *implicit include* which provides the #defines etc.

-Chris

> 
> Right now I'm staring into TokenKinds.def.  One issue there is the use of
> KEYALL for
> 
> a) non-C99 (and hence automatically non-OpenCL) keywords (e.g. __func__)
> b) GNU extensions (e.g. _Decimal32, __builtin_choose_expr) 
> c) MS extensions (e.g. __forceinline and __declspec).  
> 
> This means that a Clang-based OpenCL front-end may not accept these as valid
> identifiers, although the standard does not list them as keywords!  It's
> easy to make existing keywords valid for OpenCL but it's not so easy to
> exclude them (e.g. valid in almost all C variants but invalid in OpenCL).
> 
> I appreciate many people are busy with preparing for release 2.7 but this is
> something we should address sooner rather than later.
> 
> Anton L.
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev