[cfe-dev] [RFC] New file extension for compiling C++ for OpenCL sources

[Anastasia Stulova via cfe-dev]

FYI in my initial patch (https://reviews.llvm.org/D96771), I am adding TY_CLXX,
but it was done mainly for the orthogonality rather than any functionality.

In a long term, I imagine the OpenCL C and C++ for OpenCL can start diverging
in their setup and then we would need more changes in the driver. The only
example I can think of right now is the standard libraries. But however, we don't
add any special new libraries for C++ mode yet. Do you think it is better to leave
this functionality out until we have an actual use case?

As for the other extensions (e.g. header files, pre-processed output, etc) we haven't
used any different ones from the standard C/C++ ones up to now. I imagine they are
not extremely popular and I also find adding too many of them making things
complicated and confusing too. So I don't imagine we would want to add them into
driver support.
________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Andrzej Warzynski via cfe-dev <cfe-dev at lists.llvm.org>
Sent: 18 February 2021 12:28
To: cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] [RFC] New file extension for compiling C++ for OpenCL sources

I think that there are two things. First, the file extensions on their
own. I think that it's fine to introduce e.g. .clcxx/.clcpp and make
them map to e.g. TY_CL. This won't change much from the perspective of
the driver, but end-users could start using and getting used to it. And
adoption in IDEs/CMake could start as well.

The other thing is internal representation in clangDriver. Do we need to
introduce TY_CLXX on top of TY_CL? I get the impression that TY_CL
should be fine for now. There is TY_C and TY_CXX and you will find many
places in the driver where the input type (e.g. TY_C vs TY_CXX vs
TY_Fortran) affects the logic (e.g. which headers/libs/search-paths to
include).

For Fortran, extensions are used to differentiate between:
   * fixed-form, free-form
   * pre-processed, not-pre-processed
   * various language standards
(personally I find this very confusing). So the extensions matters a lot
and affects various stages of the compilation (e.g. preprocessing,
parsing & sema). Some of the resulting logic lives in clangDriver, some
of it in the new Flang frontend driver. Do you think that we will need
such logic to differentiate between C and C++ OpenCL source files?

I get the impression that in order to support what's currently required,
we don't need TY_CLXX just yet. But I'm also an OpenCL outsider and I
might be missing something here :)

-Andrzej


On 18/02/2021 11:40, Anastasia Stulova via cfe-dev wrote:
> Good point - another similar example would be the syntax highlight
> in the IDEs or editors that frequently use the file extensions too.
>
> ------------------------------------------------------------------------
> *From:* cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Stephen
> Kelly via cfe-dev <cfe-dev at lists.llvm.org>
> *Sent:* 17 February 2021 22:12
> *To:* cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] [RFC] New file extension for compiling C++ for
> OpenCL sources
>
> On 17/02/2021 16:36, Arthur O'Dwyer via cfe-dev wrote:
>> FWIW, as a complete outsider, as a complete non-user of OpenCL (but a
>> heavy user of C++), I don't see why a new filename extension is a good
>> thing.
>
>
> I'm also an opencl outsider.
>
> However, if opencl files are to be detected by a buildsystem like (but
> not limited to) cmake, then a file extension is a good thing. Consider
> this cmake code:
>
> cmake_minimum_required(VERSION 3.10)
>
> project(testproj C CXX OBJCXX OBJC)
>
> add_library(test
>  ���� test.cpp
>  ���� test.c
>  ���� test.m
>  ���� test.mm
> )
>
>
> CMake detects the source-language of each source file and uses the
> appropriate driver and language compile option for each one.
>
> With a file extension for opencl, CMake could use the appropriate
> driver/option for that language too. Without a distinct file extension
> for it, the user would have to tell cmake what the language is, which is
> inconvenient for the user.
>
> Thanks,
>
> Stephen.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210218/476bb79e/attachment-0001.html>