<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
Just to summarize - it seems that both '.cppcl' and '.clcpp' would be viable
<div>options. </div>
<div><br>
</div>
<div>While this survey shows that the preference is slightly towards '.cppcl', we
</div>
<div>have discussed this further on the review (https://reviews.llvm.org/D96771) and
</div>
<div>it seems '.clcpp' would be more in alignment with '-cl-std' option that accepts
</div>
<div>"cl" for OpenCL C and "clc++" for C++ for OpenCL. Therefore the proposed </div>
<div>interface would be as follows: </div>
<div><br>
</div>
<div>
<ul>
<li>OpenCL C has default '-cl-std=cl' and file extension '.cl'.</li><li>C++ for OpenCL has default '-cl-std=clc++' and file extension '.clcpp'. </li></ul>
</div>
<div><br>
</div>
<div>Note that the extension '.clc++' would be even more aligned with '-cl-std' but
</div>
<div>however clang uses '.cpp' as the main extension for C++. </div>
<div><br>
</div>
<div>Let me know if you have any more input. </div>
<div><br>
</div>
<div>Thanks,</div>
<div>Anastasia<br>
</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Andrzej Warzynski <Andrzej.Warzynski@arm.com><br>
<b>Sent:</b> 19 February 2021 16:02<br>
<b>To:</b> Anastasia Stulova <Anastasia.Stulova@arm.com><br>
<b>Cc:</b> cfe-dev@lists.llvm.org <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] New file extension for compiling C++ for OpenCL sources</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">I think that TY_CLXX could be a bit confusing at this point. It makes no
<br>
real difference in the compiler driver at this moment (i.e. OpenCL C and <br>
OpenCL C++ are treated identically regardless).<br>
<br>
Separately, in the frontend driver, you can set the language to <br>
`OpenCLCXX` based on the file extension. This way you get rid of the <br>
need for `-cl-std=clc++` as OpenCL C++ files can be identified based on <br>
the extension in the frontend. Basically what you do you in your patch :)<br>
<br>
So yes, I would leave TY_CLXX out for now. [*]<br>
<br>
As for file extensions - this change makes `-cl-std=clc++` a rather <br>
obscure flag (for e.g. compiling *.cl files as OpenCL C++ files). I <br>
think that what you are proposing is a great improvement, thank you!<br>
<br>
FWIW, there is way too many flags in Options.td. Less is more :)<br>
<br>
-Andrzej<br>
<br>
[*] Unless I've missed something and it's actually needed.<br>
<br>
On 18/02/2021 16:47, Anastasia Stulova wrote:<br>
> FYI in my initial patch (<a href=""></a>https://reviews.llvm.org/D96771 <br>
> <<a href="https://reviews.llvm.org/D96771">https://reviews.llvm.org/D96771</a>>), I am adding TY_CLXX,<br>
> but it was done mainly for the orthogonality rather than any functionality.<br>
> <br>
> In a long term, I imagine the OpenCL C and C++ for OpenCL can start <br>
> diverging<br>
> in their setup and then we would need more changes in the driver. The only<br>
> example I can think of right now is the standard libraries. But however, <br>
> we don't<br>
> add any special new libraries for C++ mode yet. Do you think it is <br>
> better to leave<br>
> this functionality out until we have an actual use case?<br>
> <br>
> As for the other extensions (e.g. header files, pre-processed output, <br>
> etc) we haven't<br>
> used any different ones from the standard C/C++ ones up to now. I <br>
> imagine they are<br>
> not extremely popular and I also find adding too many of them making things<br>
> complicated and confusing too. So I don't imagine we would want to add <br>
> them into<br>
> driver support.<br>
> ------------------------------------------------------------------------<br>
> *From:* cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Andrzej <br>
> Warzynski via cfe-dev <cfe-dev@lists.llvm.org><br>
> *Sent:* 18 February 2021 12:28<br>
> *To:* cfe-dev@lists.llvm.org <cfe-dev@lists.llvm.org><br>
> *Subject:* Re: [cfe-dev] [RFC] New file extension for compiling C++ for <br>
> OpenCL sources<br>
> I think that there are two things. First, the file extensions on their<br>
> own. I think that it's fine to introduce e.g. .clcxx/.clcpp and make<br>
> them map to e.g. TY_CL. This won't change much from the perspective of<br>
> the driver, but end-users could start using and getting used to it. And<br>
> adoption in IDEs/CMake could start as well.<br>
> <br>
> The other thing is internal representation in clangDriver. Do we need to<br>
> introduce TY_CLXX on top of TY_CL? I get the impression that TY_CL<br>
> should be fine for now. There is TY_C and TY_CXX and you will find many<br>
> places in the driver where the input type (e.g. TY_C vs TY_CXX vs<br>
> TY_Fortran) affects the logic (e.g. which headers/libs/search-paths to<br>
> include).<br>
> <br>
> For Fortran, extensions are used to differentiate between:<br>
> * fixed-form, free-form<br>
> * pre-processed, not-pre-processed<br>
> * various language standards<br>
> (personally I find this very confusing). So the extensions matters a lot<br>
> and affects various stages of the compilation (e.g. preprocessing,<br>
> parsing & sema). Some of the resulting logic lives in clangDriver, some<br>
> of it in the new Flang frontend driver. Do you think that we will need<br>
> such logic to differentiate between C and C++ OpenCL source files?<br>
> <br>
> I get the impression that in order to support what's currently required,<br>
> we don't need TY_CLXX just yet. But I'm also an OpenCL outsider and I<br>
> might be missing something here :)<br>
> <br>
> -Andrzej<br>
> <br>
> <br>
> On 18/02/2021 11:40, Anastasia Stulova via cfe-dev wrote:<br>
>> Good point - another similar example would be the syntax highlight<br>
>> in the IDEs or editors that frequently use the file extensions too.<br>
>> <br>
>> ------------------------------------------------------------------------<br>
>> *From:* cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Stephen <br>
>> Kelly via cfe-dev <cfe-dev@lists.llvm.org><br>
>> *Sent:* 17 February 2021 22:12<br>
>> *To:* cfe-dev@lists.llvm.org <cfe-dev@lists.llvm.org><br>
>> *Subject:* Re: [cfe-dev] [RFC] New file extension for compiling C++ for <br>
>> OpenCL sources<br>
>> <br>
>> On 17/02/2021 16:36, Arthur O'Dwyer via cfe-dev wrote:<br>
>>> FWIW, as a complete outsider, as a complete non-user of OpenCL (but a <br>
>>> heavy user of C++), I don't see why a new filename extension is a good <br>
>>> thing. <br>
>> <br>
>> <br>
>> I'm also an opencl outsider.<br>
>> <br>
>> However, if opencl files are to be detected by a buildsystem like (but<br>
>> not limited to) cmake, then a file extension is a good thing. Consider<br>
>> this cmake code:<br>
>> <br>
>> cmake_minimum_required(VERSION 3.10)<br>
>> <br>
>> project(testproj C CXX OBJCXX OBJC)<br>
>> <br>
>> add_library(test<br>
>> ���� test.cpp<br>
>> ���� test.c<br>
>> ���� test.m<br>
>> ���� test.mm<br>
>> )<br>
>> <br>
>> <br>
>> CMake detects the source-language of each source file and uses the<br>
>> appropriate driver and language compile option for each one.<br>
>> <br>
>> With a file extension for opencl, CMake could use the appropriate<br>
>> driver/option for that language too. Without a distinct file extension<br>
>> for it, the user would have to tell cmake what the language is, which is<br>
>> inconvenient for the user.<br>
>> <br>
>> Thanks,<br>
>> <br>
>> Stephen.<br>
>> <br>
>> <br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> cfe-dev@lists.llvm.org<br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
<br>
> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>><br>
>> <<a href=""></a>https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <br>
> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>>><br>
>> <br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> cfe-dev@lists.llvm.org<br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
<br>
> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>><br>
>> <br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> cfe-dev@lists.llvm.org<br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
<br>
> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>><br>
</div>
</span></font></div>
</body>
</html>