<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#993366;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle29
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle30
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle31
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle32
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="RU" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span lang="EN-US" style="color:#1F497D;mso-fareast-language:EN-US">I think TargetInfo is intended for features supported by HW, whereas OpenCL extensions and optional core features are defined by “OpenCL device”.<o:p></o:p></span></a></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D;mso-fareast-language:EN-US">From my experience I can say that some OpenCL implementations doesn’t support extensions/features that available in HW.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Alexey<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><a name="_____replyseparator"></a><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Liu, Yaxun (Sam) [mailto:Yaxun.Liu@amd.com]
<br>
<b>Sent:</b> Thursday, April 21, 2016 6:38 PM<br>
<b>To:</b> Bader, Alexey; Anastasia Stulova; cfe-dev (cfe-dev@lists.llvm.org)<br>
<b>Cc:</b> Sumner, Brian; Pan, Xiuli; nd<br>
<b>Subject:</b> RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I think we need sth like SupportedOpenCLExtensionsAndOptionalCoreFeatures in TargetInfo. Then we can let each target define supported OpenCL extensions and core features. Then we add SupportedOpenCLCoreFeatures
to Sema based on TargetInfo, and use it to diagnose if unsupported OpenCL core features are used.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">For SPIR target, we just enable all the extensions and optional core features since it is offline compiler.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Sam<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Bader, Alexey [<a href="mailto:alexey.bader@intel.com">mailto:alexey.bader@intel.com</a>]
<br>
<b>Sent:</b> Thursday, April 21, 2016 11:06 AM<br>
<b>To:</b> Anastasia Stulova <<a href="mailto:Anastasia.Stulova@arm.com">Anastasia.Stulova@arm.com</a>>; Liu, Yaxun (Sam) <<a href="mailto:Yaxun.Liu@amd.com">Yaxun.Liu@amd.com</a>>; cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>)
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
<b>Cc:</b> Sumner, Brian <<a href="mailto:Brian.Sumner@amd.com">Brian.Sumner@amd.com</a>>; Pan, Xiuli <<a href="mailto:xiuli.pan@intel.com">xiuli.pan@intel.com</a>>; nd <<a href="mailto:nd@arm.com">nd@arm.com</a>><br>
<b>Subject:</b> RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">> I am not quite clear how does the command line flag help us or how is it different from enabling the pragma?
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">Flag says whether ‘optional core feature’ is supported by the device or not. If the feature is not supported, but it’s used in the program, compiler should report an error.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">The difference between ‘optional core feature’ and ‘language extension’ is that pragma is required only for extensions.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">> If the flag is being passed but the target doesn’t support the extension what should happen then?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">It would be OpenCL run-time error. ‘Flag solution’ implies that it’s OpenCL run-time responsibility to set the flags that configures clang to enable/disable optional core features support. It’s not
user’s responsibility in case of online compilation.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">Offline compilers (e.g. SPIR generators) should implicitly enable all optional core features/extensions at compile time and let the OpenCL run-time to reject the SPIR files that require unsupported
features at run time. Flags are helpful for vendor specific compiler that should enable only extensions supported by vendor’s devices.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">> My understanding of what we are missing in Clang is a way to specify and know what extensions are supported by the target compiled for. We currently have an extension list which are enabled, but
the list of supported extensions (to be enabled) is missing, which could come from the target info in my opinion or some sort of that. Not sure it’s correct to have it given from the user. What do you think about this?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">You are right. The same problem as Sam described for ‘doubles’ optional core feature is also applied to the OpenCL kernel language extensions.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">I just realized that I open sourced Intel’s implementation of the check if extension supported by the device or not with SPIR-V generator.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">We added this list of options to clang::PreprocessorOptions and we enable only extensions that are passed to the clang from the run-time.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">You can take a look at that approach at
</span><span lang="EN-US"><a href="https://github.com/KhronosGroup/SPIR/blob/spirv-1.0/include/clang/Basic/LangOptions.h#L142"><span lang="EN-GB">include\clang\Basic\LangOptions.h</span></a></span><span lang="EN-GB" style="color:#1F497D"> and
</span><span lang="EN-US"><a href="https://github.com/KhronosGroup/SPIR/blob/spirv-1.0/include/clang/Lex/Preprocessor.h#L504"><span lang="EN-GB">include\clang\Lex\Preprocessor.h</span></a></span><span lang="EN-GB" style="color:#1F497D"> files.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">This is alternative solution to the flags, but out implementation works only for extensions and online compilers.
</span><span lang="EN-US" style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Alexey<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Anastasia Stulova [<a href="mailto:Anastasia.Stulova@arm.com">mailto:Anastasia.Stulova@arm.com</a>]
<br>
<b>Sent:</b> Thursday, April 21, 2016 1:47 PM<br>
<b>To:</b> Bader, Alexey; Liu, Yaxun (Sam); cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>)<br>
<b>Cc:</b> Sumner, Brian; Pan, Xiuli; nd<br>
<b>Subject:</b> RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">I am not quite clear how does the command line flag help us or how is it different from enabling the pragma? If the flag is being passed but the target doesn’t support the extension what should happen
then?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">My understanding of what we are missing in Clang is a way to specify and know what extensions are supported by the target compiled for. We currently have an extension list which are enabled, but
the list of supported extensions (to be enabled) is missing, which could come from the target info in my opinion or some sort of that. Not sure it’s correct to have it given from the user. What do you think about this?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D">Anastasia <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> Bader, Alexey [</span><span lang="EN-US"><a href="mailto:alexey.bader@intel.com"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">mailto:alexey.bader@intel.com</span></a></span><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif">]
<br>
<b>Sent:</b> 20 April 2016 16:07<br>
<b>To:</b> Liu, Yaxun (Sam); cfe-dev (</span><span lang="EN-US"><a href="mailto:cfe-dev@lists.llvm.org"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">cfe-dev@lists.llvm.org</span></a></span><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif">)<br>
<b>Cc:</b> Anastasia Stulova; Sumner, Brian; Pan, Xiuli<br>
<b>Subject:</b> RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#993366">In addition to that we will have to modify diagnostics message a bit:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-US" style="color:#993366">-</span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#993366">
</span><span lang="EN-US" style="color:#993366">for OpenCL before v1.2 we should require cl_khr_fp64 (as it’s done right now)<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt"><span lang="EN-US" style="color:#993366">-</span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#993366">
</span><span lang="EN-US" style="color:#993366">for OpenCL v1.2+ let user know that doubles are not supported by the platform if it’s not enabled by compiler option.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#993366"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#993366">Does it make sense?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#993366"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:#993366">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#993366">Alexey<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Liu, Yaxun (Sam) [<a href="mailto:Yaxun.Liu@amd.com">mailto:Yaxun.Liu@amd.com</a>]
<br>
<b>Sent:</b> Wednesday, April 20, 2016 6:03 PM<br>
<b>To:</b> Bader, Alexey; cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>)<br>
<b>Cc:</b> 'anastasia.stulova@arm.com'; Sumner, Brian; Pan, Xiuli<br>
<b>Subject:</b> RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Then we can let Clang define macro cl_khr_fp64 when cl-fp64-enable is on. Then the header file will use #ifdef cl_khr_fp64 to enable double type builtin functions.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Sam<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Liu, Yaxun (Sam)
<br>
<b>Sent:</b> Wednesday, April 20, 2016 11:00 AM<br>
<b>To:</b> 'Bader, Alexey' <<a href="mailto:alexey.bader@intel.com">alexey.bader@intel.com</a>>; cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>) <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
<b>Cc:</b> 'anastasia.stulova@arm.com' <<a href="mailto:anastasia.stulova@arm.com">anastasia.stulova@arm.com</a>>; Sumner, Brian <<a href="mailto:Brian.Sumner@amd.com">Brian.Sumner@amd.com</a>>; Pan, Xiuli <<a href="mailto:xiuli.pan@intel.com">xiuli.pan@intel.com</a>><br>
<b>Subject:</b> RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">We can use that.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Currently double is automatically enabled in Clang for –cl-std=CL2.0. We could enable double only under cl-fp64-enable.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Sam<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Bader, Alexey [<a href="mailto:alexey.bader@intel.com">mailto:alexey.bader@intel.com</a>]
<br>
<b>Sent:</b> Wednesday, April 20, 2016 10:56 AM<br>
<b>To:</b> Liu, Yaxun (Sam) <<a href="mailto:Yaxun.Liu@amd.com">Yaxun.Liu@amd.com</a>>; cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>) <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
<b>Cc:</b> 'anastasia.stulova@arm.com' <<a href="mailto:anastasia.stulova@arm.com">anastasia.stulova@arm.com</a>>; Sumner, Brian <<a href="mailto:Brian.Sumner@amd.com">Brian.Sumner@amd.com</a>>; Pan, Xiuli <<a href="mailto:xiuli.pan@intel.com">xiuli.pan@intel.com</a>><br>
<b>Subject:</b> RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">One correction: doubles became optional core feature in OpenCL 1.2.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I’m agree that it’s a bug, but I’d like to discuss the ideas on how to fix it.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">There should be some way to let clang know that doubles are not supported by OpenCL platform and it’s expected to get diagnostics in this case.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">OpenCL C++ compiler introduces compiler knob for that. “cl-fp64-enable”<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><a href="https://github.com/KhronosGroup/SPIR/blob/spirv-1.1/include/clang/Driver/CC1Options.td#L606">https://github.com/KhronosGroup/SPIR/blob/spirv-1.1/include/clang/Driver/CC1Options.td#L606</a><span style="color:#1F497D"><o:p></o:p></span></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Alexey<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Liu, Yaxun (Sam) [<a href="mailto:Yaxun.Liu@amd.com">mailto:Yaxun.Liu@amd.com</a>]
<br>
<b>Sent:</b> Wednesday, April 20, 2016 5:45 PM<br>
<b>To:</b> cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>)<br>
<b>Cc:</b> 'anastasia.stulova@arm.com'; Sumner, Brian; Pan, Xiuli; Bader, Alexey<br>
<b>Subject:</b> [OpenCL] atomic_double requires cl_khr_fp64 enabled<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Currently Clang requires cl_khr_fp64 enabled to use atomic_double. This seems to be a bug.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">In OpenCL 2.0 fp64 is an optional feature. If platform supports it, there is no need to enable cl_khr_fp64 to use it. Actually in OpenCL 2.0 spec cl_khr_fp64 is not defined.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I plan to fix that if all agree it is a bug.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">What’s your opinion? Thanks.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Sam<o:p></o:p></span></p>
<p><br>
--------------------------------------------------------------------<br>
Joint Stock Company Intel A/O<br>
Registered legal address: Krylatsky Hills Business Park, <br>
17 Krylatskaya Str., Bldg 4, Moscow 121614, <br>
Russian Federation<o:p></o:p></p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<o:p></o:p></p>
<p><br>
--------------------------------------------------------------------<br>
Joint Stock Company Intel A/O<br>
Registered legal address: Krylatsky Hills Business Park, <br>
17 Krylatskaya Str., Bldg 4, Moscow 121614, <br>
Russian Federation<o:p></o:p></p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<o:p></o:p></p>
<p><br>
--------------------------------------------------------------------<br>
Joint Stock Company Intel A/O<br>
Registered legal address: Krylatsky Hills Business Park, <br>
17 Krylatskaya Str., Bldg 4, Moscow 121614, <br>
Russian Federation<o:p></o:p></p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.<o:p></o:p></p>
</div>
<p><br>--------------------------------------------------------------------<br>Joint Stock Company Intel A/O<br>Registered legal address: Krylatsky Hills Business Park, <br>17 Krylatskaya Str., Bldg 4, Moscow 121614, <br>Russian Federation</p><p>This e-mail and any attachments may contain confidential material for<br>the sole use of the intended recipient(s). Any review or distribution<br>by others is strictly prohibited. If you are not the intended<br>recipient, please contact the sender and delete all copies.</p>
</body>
</html>