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

[Anastasia Stulova via cfe-dev]

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?

I think the comparison to Objective-C++ is probably the best way to position
C++ for OpenCL. OpenCL C also had a distinct extension from C. But I somehow
find it natural to add a separate one for C++ for OpenCL. I guess the advantage
is even if the language might evolve and more versions will likely be added
we can still choose the default one that can work for most cases. For example,
we can always reset it to the latest one or most used one. Although I
appreciate this doesn't always happen. For OpenCL C we still use the first
version as default. However, I do admit it has most of the common
functionality.

There are also other useful aspects that are not compiler related though like
build system or syntax highlight that can use the file extensions. It makes
sense if they work with the same standardized extension rather than using
different ones.
________________________________
From: Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
Sent: 17 February 2021 20:43
To: Anastasia Stulova <Anastasia.Stulova at arm.com>
Cc: clang developer list <cfe-dev at lists.llvm.org>; nd <nd at arm.com>; Andrzej Warzynski <Andrzej.Warzynski at arm.com>
Subject: Re: [cfe-dev] [RFC] New file extension for compiling C++ for OpenCL sources

On Wed, Feb 17, 2021 at 1:56 PM Anastasia Stulova <Anastasia.Stulova at arm.com<mailto: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/20210218/a4caf013/attachment-0001.html>