Re: [cfe-commits] r170428 [1/3] - in /cfe/trunk: include/clang/AST/ include/clang/Basic/ include/clang/Sema/ include/clang/Serialization/ lib/AST/ lib/CodeGen/ lib/Parse/ lib/Sema/ lib/Serialization/

2016-02-03 Thread Aleksey Bader via cfe-commits
FYI: OpenCL is planning to add C++ flavor of kernel language:
https://www.khronos.org/registry/cl/specs/opencl-2.1-openclc++.pdf

On Wed, Feb 3, 2016 at 12:04 PM, Benyei, Guy via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi Richard,
> Since these are OpenCL specific types, I think you are right,  these types
> shouldn't be part of the C++ ABI library.
>
> Thanks
>  Guy
>
> -Original Message-
> From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard
> Smith
> Sent: Wednesday, February 03, 2016 02:46
> To: Benyei, Guy ; cfe-commits <
> cfe-commits@lists.llvm.org>
> Subject: Fwd: [cfe-commits] r170428 [1/3] - in /cfe/trunk:
> include/clang/AST/ include/clang/Basic/ include/clang/Sema/
> include/clang/Serialization/ lib/AST/ lib/CodeGen/ lib/Parse/ lib/Sema/
> lib/Serialization/ test/CodeGenOpenCL/ test/PCH/ test/Parser/ tools/li...
>
> Hi Guy,
>
> > Modified: cfe/trunk/lib/CodeGen/CGRTTI.cpp
> > URL:
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGRTTI.cpp?r
> > ev=170428&r1=170427&r2=170428&view=diff
> > ==
> > 
> > --- cfe/trunk/lib/CodeGen/CGRTTI.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CGRTTI.cpp Tue Dec 18 06:30:03 2012
> > @@ -1,1011 +1,1017 @@
> [...]
> > -/// TypeInfoIsInStandardLibrary - Given a builtin type, returns
> > whether the type -/// info for that type is defined in the standard
> library.
> > -static bool TypeInfoIsInStandardLibrary(const BuiltinType *Ty) {
> > -  // Itanium C++ ABI 2.9.2:
> > -  //   Basic type information (e.g. for "int", "bool", etc.) will be
> kept in
> > -  //   the run-time support library. Specifically, the run-time support
> > -  //   library should contain type_info objects for the types X, X* and
> > -  //   X const*, for every X in: void, std::nullptr_t, bool, wchar_t,
> char,
> > -  //   unsigned char, signed char, short, unsigned short, int, unsigned
> int,
> > -  //   long, unsigned long, long long, unsigned long long, float,
> double,
> > -  //   long double, char16_t, char32_t, and the IEEE 754r decimal and
> > -  //   half-precision floating point types.
> > -  switch (Ty->getKind()) {
> > -case BuiltinType::Void:
> > -case BuiltinType::NullPtr:
> > -case BuiltinType::Bool:
> > -case BuiltinType::WChar_S:
> > -case BuiltinType::WChar_U:
> > -case BuiltinType::Char_U:
> > -case BuiltinType::Char_S:
> > -case BuiltinType::UChar:
> > -case BuiltinType::SChar:
> > -case BuiltinType::Short:
> > -case BuiltinType::UShort:
> > -case BuiltinType::Int:
> > -case BuiltinType::UInt:
> > -case BuiltinType::Long:
> > -case BuiltinType::ULong:
> > -case BuiltinType::LongLong:
> > -case BuiltinType::ULongLong:
> > -case BuiltinType::Half:
> > -case BuiltinType::Float:
> > -case BuiltinType::Double:
> > -case BuiltinType::LongDouble:
> > -case BuiltinType::Char16:
> > -case BuiltinType::Char32:
> > -case BuiltinType::Int128:
> > -case BuiltinType::UInt128:
> > -  return true;
> > +/// TypeInfoIsInStandardLibrary - Given a builtin type, returns
> > +whether the type /// info for that type is defined in the standard
> library.
> > +static bool TypeInfoIsInStandardLibrary(const BuiltinType *Ty) {
> > +  // Itanium C++ ABI 2.9.2:
> > +  //   Basic type information (e.g. for "int", "bool", etc.) will be
> kept in
> > +  //   the run-time support library. Specifically, the run-time support
> > +  //   library should contain type_info objects for the types X, X* and
> > +  //   X const*, for every X in: void, std::nullptr_t, bool, wchar_t,
> char,
> > +  //   unsigned char, signed char, short, unsigned short, int, unsigned
> int,
> > +  //   long, unsigned long, long long, unsigned long long, float,
> double,
> > +  //   long double, char16_t, char32_t, and the IEEE 754r decimal and
> > +  //   half-precision floating point types.
> > +  switch (Ty->getKind()) {
> > +case BuiltinType::Void:
> > +case BuiltinType::NullPtr:
> > +case BuiltinType::Bool:
> > +case BuiltinType::WChar_S:
> > +case BuiltinType::WChar_U:
> > +case BuiltinType::Char_U:
> > +case BuiltinType::Char_S:
> > +case BuiltinType::UChar:
> > +case BuiltinType::SChar:
> > +case BuiltinType::Short:
> > +case BuiltinType::UShort:
> > +case BuiltinType::Int:
> > +case BuiltinType::UInt:
> > +case BuiltinType::Long:
> > +case BuiltinType::ULong:
> > +case BuiltinType::LongLong:
> > +case BuiltinType::ULongLong:
> > +case BuiltinType::Half:
> > +case BuiltinType::Float:
> > +case BuiltinType::Double:
> > +case BuiltinType::LongDouble:
> > +case BuiltinType::Char16:
> > +case BuiltinType::Char32:
> > +case BuiltinType::Int128:
> > +case BuiltinType::UInt128:
> > +case BuiltinType::OCLImage1d:
> > +case BuiltinType::OCLImage1dArray:
> > +case BuiltinType::OCLImage1dBuffer:
> > +

Re: [PATCH] D20602: Add .rgba syntax extension to ext_vector_type types

2016-05-25 Thread Aleksey Bader via cfe-commits
On Wed, May 25, 2016 at 11:53 PM, Richard Smith 
wrote:

> On Wed, May 25, 2016 at 2:20 AM, Alexey Bader via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> bader added a subscriber: bader.
>> bader added a comment.
>>
>> In http://reviews.llvm.org/D20602#438667, @rsmith wrote:
>>
>> > I'm not suggesting it be treated as invalid. This extension is part of
>> at least OpenCL 2.1, but it's not part of OpenCL 1.0. `ext_vector_type` is
>> Clang's implementation of the OpenCL vector type. Therefore if the user
>> asks us to support OpenCL 1.0, we should give them a warning if they use
>> this syntax.
>> >
>> > If we're not building an OpenCL source file, then yes, this is our
>> extension and it makes sense for it to be available unconditionally
>> (without a warning).
>>
>>
>> To avoid confusion, I'd like to note that rgba selector was first
>> introduced in OpenCL C++ kernel language, which is currently in provisional
>> state and will be part of OpenCL version 2.2.
>> https://www.khronos.org/registry/cl/specs/opencl-2.2-cplusplus.pdf (page
>> 18).
>>
>
> https://www.khronos.org/registry/cl/specs/opencl-2.1-openclc++.pdf page
> 12-13 document it. Is that not OpenCL version 2.1?
>
>

Not quite. OpenCL C++ kernel language was planned to be ratified with
OpenCL 2.1 standard, but it did happen.
It's still listed as provisional although OpenCL 2.1 specification was
released last year. https://www.khronos.org/opencl/
Ratified OpenCL 2.1 standard requires to support only OpenCL C 2.0 and
SPIR-V 1.0 kernel languages.
There is no much sense to support provisional specification that will never
be ratified.

BTW, Khronos provided open source implementation of OpenCL C++ compiler and
since OpenCL C++ is a new kernel language and specification (
https://www.khronos.org/registry/cl/specs/opencl-2.2-cplusplus.pdf) is
version 1.0, the numbering of standard versions is different from OpenCL C.
Current std version is 'c++'.
Here is usage example:
https://github.com/KhronosGroup/SPIR/blob/spirv-1.1/test/OpenCL/OpenCL22/opencl_cplusplus.cl


> OpenCL version 2.1 uses OpenCL C 2.0 kernel language, which doesn't
>> support rgba selector.
>>
>> https://www.khronos.org/registry/cl/ - latest versions of OpenCL specs.
>>
>>
>> http://reviews.llvm.org/D20602
>>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits