Re: r369749 - [Docs][OpenCL] Several corrections to C++ for OpenCL
Yes, r370031. Thanks, Hans On Tue, Aug 27, 2019 at 11:43 AM Anastasia Stulova wrote: > > Hi Hans, > > > Can this be merged to the release, please? > > > Thank you, > > Anastasia > > > > > From: cfe-commits on behalf of Anastasia > Stulova via cfe-commits > Sent: 23 August 2019 12:43 > To: cfe-commits@lists.llvm.org > Subject: r369749 - [Docs][OpenCL] Several corrections to C++ for OpenCL > > Author: stulova > Date: Fri Aug 23 04:43:49 2019 > New Revision: 369749 > > URL: http://llvm.org/viewvc/llvm-project?rev=369749=rev > Log: > [Docs][OpenCL] Several corrections to C++ for OpenCL > > Differential Revision:https://reviews.llvm.org/D64418 > > > Modified: > cfe/trunk/docs/LanguageExtensions.rst > cfe/trunk/docs/UsersManual.rst > > Modified: cfe/trunk/docs/LanguageExtensions.rst > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=369749=369748=369749=diff > == > --- cfe/trunk/docs/LanguageExtensions.rst (original) > +++ cfe/trunk/docs/LanguageExtensions.rst Fri Aug 23 04:43:49 2019 > @@ -1640,8 +1640,8 @@ OpenCL Features > C++ for OpenCL > -- > > -This functionality is built on top of OpenCL C v2.0 and C++17. Regular C++ > -features can be used in OpenCL kernel code. All functionality from OpenCL C > +This functionality is built on top of OpenCL C v2.0 and C++17 enabling most > of > +regular C++ features in OpenCL kernel code. Most functionality from OpenCL C > is inherited. This section describes minor differences to OpenCL C and any > limitations related to C++ support as well as interactions between OpenCL and > C++ features that are not documented elsewhere. > @@ -1652,6 +1652,7 @@ Restrictions to C++17 > The following features are not supported: > > - Virtual functions > +- Exceptions > - ``dynamic_cast`` operator > - Non-placement ``new``/``delete`` operators > - Standard C++ libraries. Currently there is no solution for alternative C++ > @@ -1667,20 +1668,24 @@ Address space behavior > Address spaces are part of the type qualifiers; many rules are just inherited > from the qualifier behavior documented in OpenCL C v2.0 s6.5 and Embedded C > extension ISO/IEC JTC1 SC22 WG14 N1021 s3.1. Note that since the address > space > -behavior in C++ is not documented formally yet, Clang extends existing > concept > +behavior in C++ is not documented formally, Clang extends the existing > concept > from C and OpenCL. For example conversion rules are extended from > qualification > -conversion but the compatibility is determined using sets and overlapping > from > -Embedded C (ISO/IEC JTC1 SC22 WG14 N1021 s3.1.3). For OpenCL it means that > -implicit conversions are allowed from named to ``__generic`` but not vice > versa > -(OpenCL C v2.0 s6.5.5) except for ``__constant`` address space. Most of the > -rules are built on top of this behavior. > +conversion but the compatibility is determined using notation of sets and > +overlapping of address spaces from Embedded C (ISO/IEC JTC1 SC22 WG14 N1021 > +s3.1.3). For OpenCL it means that implicit conversions are allowed from > +a named address space (except for ``__constant``) to ``__generic`` (OpenCL C > +v2.0 6.5.5). Reverse conversion is only allowed explicitly. The > ``__constant`` > +address space does not overlap with any other and therefore no valid > conversion > +between ``__constant`` and other address spaces exists. Most of the rules > +follow this logic. > > **Casts** > > -C style cast will follow OpenCL C v2.0 rules (s6.5.5). All cast operators > will > -permit implicit conversion to ``__generic``. However converting from named > -address spaces to ``__generic`` can only be done using ``addrspace_cast``. > Note > -that conversions between ``__constant`` and any other is still disallowed. > +C-style casts follow OpenCL C v2.0 rules (s6.5.5). All cast operators > +permit conversion to ``__generic`` implicitly. However converting from > +``__generic`` to named address spaces can only be done using > ``addrspace_cast``. > +Note that conversions between ``__constant`` and any other address space > +are disallowed. > > .. _opencl_cpp_addrsp_deduction: > > @@ -1693,7 +1698,7 @@ Address spaces are not deduced for: > - non-pointer/non-reference class members except for static data members > that are >deduced to ``__global`` address space. > - non-pointer/non-reference alias declarations. > -- ``decltype`` expression. > +- ``decltype`` expressions. > > .. code-block:: c++ > > @@ -1722,7 +1727,7 @@ TODO: Add e
Re: r369749 - [Docs][OpenCL] Several corrections to C++ for OpenCL
Hi Hans, Can this be merged to the release, please? Thank you, Anastasia From: cfe-commits on behalf of Anastasia Stulova via cfe-commits Sent: 23 August 2019 12:43 To: cfe-commits@lists.llvm.org Subject: r369749 - [Docs][OpenCL] Several corrections to C++ for OpenCL Author: stulova Date: Fri Aug 23 04:43:49 2019 New Revision: 369749 URL: http://llvm.org/viewvc/llvm-project?rev=369749=rev Log: [Docs][OpenCL] Several corrections to C++ for OpenCL Differential Revision:https://reviews.llvm.org/D64418 Modified: cfe/trunk/docs/LanguageExtensions.rst cfe/trunk/docs/UsersManual.rst Modified: cfe/trunk/docs/LanguageExtensions.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=369749=369748=369749=diff == --- cfe/trunk/docs/LanguageExtensions.rst (original) +++ cfe/trunk/docs/LanguageExtensions.rst Fri Aug 23 04:43:49 2019 @@ -1640,8 +1640,8 @@ OpenCL Features C++ for OpenCL -- -This functionality is built on top of OpenCL C v2.0 and C++17. Regular C++ -features can be used in OpenCL kernel code. All functionality from OpenCL C +This functionality is built on top of OpenCL C v2.0 and C++17 enabling most of +regular C++ features in OpenCL kernel code. Most functionality from OpenCL C is inherited. This section describes minor differences to OpenCL C and any limitations related to C++ support as well as interactions between OpenCL and C++ features that are not documented elsewhere. @@ -1652,6 +1652,7 @@ Restrictions to C++17 The following features are not supported: - Virtual functions +- Exceptions - ``dynamic_cast`` operator - Non-placement ``new``/``delete`` operators - Standard C++ libraries. Currently there is no solution for alternative C++ @@ -1667,20 +1668,24 @@ Address space behavior Address spaces are part of the type qualifiers; many rules are just inherited from the qualifier behavior documented in OpenCL C v2.0 s6.5 and Embedded C extension ISO/IEC JTC1 SC22 WG14 N1021 s3.1. Note that since the address space -behavior in C++ is not documented formally yet, Clang extends existing concept +behavior in C++ is not documented formally, Clang extends the existing concept from C and OpenCL. For example conversion rules are extended from qualification -conversion but the compatibility is determined using sets and overlapping from -Embedded C (ISO/IEC JTC1 SC22 WG14 N1021 s3.1.3). For OpenCL it means that -implicit conversions are allowed from named to ``__generic`` but not vice versa -(OpenCL C v2.0 s6.5.5) except for ``__constant`` address space. Most of the -rules are built on top of this behavior. +conversion but the compatibility is determined using notation of sets and +overlapping of address spaces from Embedded C (ISO/IEC JTC1 SC22 WG14 N1021 +s3.1.3). For OpenCL it means that implicit conversions are allowed from +a named address space (except for ``__constant``) to ``__generic`` (OpenCL C +v2.0 6.5.5). Reverse conversion is only allowed explicitly. The ``__constant`` +address space does not overlap with any other and therefore no valid conversion +between ``__constant`` and other address spaces exists. Most of the rules +follow this logic. **Casts** -C style cast will follow OpenCL C v2.0 rules (s6.5.5). All cast operators will -permit implicit conversion to ``__generic``. However converting from named -address spaces to ``__generic`` can only be done using ``addrspace_cast``. Note -that conversions between ``__constant`` and any other is still disallowed. +C-style casts follow OpenCL C v2.0 rules (s6.5.5). All cast operators +permit conversion to ``__generic`` implicitly. However converting from +``__generic`` to named address spaces can only be done using ``addrspace_cast``. +Note that conversions between ``__constant`` and any other address space +are disallowed. .. _opencl_cpp_addrsp_deduction: @@ -1693,7 +1698,7 @@ Address spaces are not deduced for: - non-pointer/non-reference class members except for static data members that are deduced to ``__global`` address space. - non-pointer/non-reference alias declarations. -- ``decltype`` expression. +- ``decltype`` expressions. .. code-block:: c++ @@ -1722,7 +1727,7 @@ TODO: Add example for type alias and dec **References** -References types can be qualified with an address space. +Reference types can be qualified with an address space. .. code-block:: c++ @@ -1737,29 +1742,29 @@ rules from address space pointer convers **Default address space** All non-static member functions take an implicit object parameter ``this`` that -is a pointer type. By default this pointer parameter is in ``__generic`` address -space. All concrete objects passed as an argument to ``this`` parameter will be -converted to ``__generic`` address space first if the conversion is valid. -Therefore programs using objects in ``__constant`` address space won't
r369749 - [Docs][OpenCL] Several corrections to C++ for OpenCL
Author: stulova Date: Fri Aug 23 04:43:49 2019 New Revision: 369749 URL: http://llvm.org/viewvc/llvm-project?rev=369749=rev Log: [Docs][OpenCL] Several corrections to C++ for OpenCL Differential Revision:https://reviews.llvm.org/D64418 Modified: cfe/trunk/docs/LanguageExtensions.rst cfe/trunk/docs/UsersManual.rst Modified: cfe/trunk/docs/LanguageExtensions.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=369749=369748=369749=diff == --- cfe/trunk/docs/LanguageExtensions.rst (original) +++ cfe/trunk/docs/LanguageExtensions.rst Fri Aug 23 04:43:49 2019 @@ -1640,8 +1640,8 @@ OpenCL Features C++ for OpenCL -- -This functionality is built on top of OpenCL C v2.0 and C++17. Regular C++ -features can be used in OpenCL kernel code. All functionality from OpenCL C +This functionality is built on top of OpenCL C v2.0 and C++17 enabling most of +regular C++ features in OpenCL kernel code. Most functionality from OpenCL C is inherited. This section describes minor differences to OpenCL C and any limitations related to C++ support as well as interactions between OpenCL and C++ features that are not documented elsewhere. @@ -1652,6 +1652,7 @@ Restrictions to C++17 The following features are not supported: - Virtual functions +- Exceptions - ``dynamic_cast`` operator - Non-placement ``new``/``delete`` operators - Standard C++ libraries. Currently there is no solution for alternative C++ @@ -1667,20 +1668,24 @@ Address space behavior Address spaces are part of the type qualifiers; many rules are just inherited from the qualifier behavior documented in OpenCL C v2.0 s6.5 and Embedded C extension ISO/IEC JTC1 SC22 WG14 N1021 s3.1. Note that since the address space -behavior in C++ is not documented formally yet, Clang extends existing concept +behavior in C++ is not documented formally, Clang extends the existing concept from C and OpenCL. For example conversion rules are extended from qualification -conversion but the compatibility is determined using sets and overlapping from -Embedded C (ISO/IEC JTC1 SC22 WG14 N1021 s3.1.3). For OpenCL it means that -implicit conversions are allowed from named to ``__generic`` but not vice versa -(OpenCL C v2.0 s6.5.5) except for ``__constant`` address space. Most of the -rules are built on top of this behavior. +conversion but the compatibility is determined using notation of sets and +overlapping of address spaces from Embedded C (ISO/IEC JTC1 SC22 WG14 N1021 +s3.1.3). For OpenCL it means that implicit conversions are allowed from +a named address space (except for ``__constant``) to ``__generic`` (OpenCL C +v2.0 6.5.5). Reverse conversion is only allowed explicitly. The ``__constant`` +address space does not overlap with any other and therefore no valid conversion +between ``__constant`` and other address spaces exists. Most of the rules +follow this logic. **Casts** -C style cast will follow OpenCL C v2.0 rules (s6.5.5). All cast operators will -permit implicit conversion to ``__generic``. However converting from named -address spaces to ``__generic`` can only be done using ``addrspace_cast``. Note -that conversions between ``__constant`` and any other is still disallowed. +C-style casts follow OpenCL C v2.0 rules (s6.5.5). All cast operators +permit conversion to ``__generic`` implicitly. However converting from +``__generic`` to named address spaces can only be done using ``addrspace_cast``. +Note that conversions between ``__constant`` and any other address space +are disallowed. .. _opencl_cpp_addrsp_deduction: @@ -1693,7 +1698,7 @@ Address spaces are not deduced for: - non-pointer/non-reference class members except for static data members that are deduced to ``__global`` address space. - non-pointer/non-reference alias declarations. -- ``decltype`` expression. +- ``decltype`` expressions. .. code-block:: c++ @@ -1722,7 +1727,7 @@ TODO: Add example for type alias and dec **References** -References types can be qualified with an address space. +Reference types can be qualified with an address space. .. code-block:: c++ @@ -1737,29 +1742,29 @@ rules from address space pointer convers **Default address space** All non-static member functions take an implicit object parameter ``this`` that -is a pointer type. By default this pointer parameter is in ``__generic`` address -space. All concrete objects passed as an argument to ``this`` parameter will be -converted to ``__generic`` address space first if the conversion is valid. -Therefore programs using objects in ``__constant`` address space won't be compiled -unless address space is explicitly specified using address space qualifiers on -member functions +is a pointer type. By default this pointer parameter is in the ``__generic`` +address space. All concrete objects passed as an argument to ``this`` parameter +will be converted to the
