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

[Arthur O'Dwyer via cfe-dev]

On Wed, Feb 17, 2021 at 1:56 PM Anastasia Stulova <Anastasia.Stulova at arm.com>
wrote:

> > Is C++-with-OpenCL really so different from the situation with C++ today?
> [...]
> Do I understand it correctly that you suggest the filename suffixes are
> not that useful and we should abandon the idea?
>

If I ran the world, yes, definitely that is my opinion.
However, mine is quite likely to be an *ill-informed* opinion, because I
don't know basically anything about the OpenCL ecosystem or even OpenCL
itself.
So you shouldn't let me run the world. :)


> Then should this apply to all or some languages?
>

It depends on how much "C++ + OpenCL" is like a dialect of C++ and how much
it's like a brand-new language.

Objective-C++ is maybe in a vaguely similar situation, and it does get its
own extension (.mm). But Objective-C++ is also:
- explicitly a cross between two "equally first-class" languages
Objective-C and C++, each of which already had its own extension (.m and
.cpp/.cc)
- perhaps thankfully moribund and maybe this is our chance to do something
different?

> Is there any appetite to create a driver alias such as "clangcl",
> analogous to what we do today with "clang++"?
>

> We had no plans for this yet.
>

I guess the typical reason to create a new driver is if you need it to do
something special at link-time, when the original filenames won't be
available. E.g.
    clang x.o y.o -o program.exe
and
    clang++ x.o y.o -o program.exe
pass different flags to the linker. I don't know if this situation applies
to OpenCL.

–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210217/e49ef70f/attachment.html>