<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">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
FYI in my initial patch (<a href="https://reviews.llvm.org/D96771" id="LPlnk">https://reviews.llvm.org/D96771</a>), I am adding
<font size="2"><span style="font-size:11pt">TY_CLXX,</span></font></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<font size="2"><span style="font-size:11pt">but it was done mainly for the orthogonality rather than any functionality.</span></font><br>
</div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>
<br>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
In a long term, I imagine the OpenCL C and C++ for OpenCL can start diverging</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
in their setup and then we would need more changes in the driver. The only</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
example I can think of right now is the standard libraries. But however, we don't</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
add any special new libraries for C++ mode yet. Do you think it is better to leave</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
this functionality out until we have an actual use case?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
As for the other extensions (e.g. header files, pre-processed output, etc) we haven't</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
used any different ones from the standard C/C++ ones up to now. I imagine they are</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
not extremely popular and I also find adding too many of them making things</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
complicated and confusing too. So I don't imagine we would want to add them into</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
driver support.<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> cfe-dev <cfe-dev-bounces@lists.llvm.org> on behalf of Andrzej Warzynski via cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Sent:</b> 18 February 2021 12:28<br>
<b>To:</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 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>
> <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>
> <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>
</div>
</span></font></div>
</body>
</html>