Thanks for the clarifications.

Interesting.

I wonder whether we could not factorize some code/attribute/logic with AMDGPU or SYCL.
Is the use case to have for example CUDA+HIP+SYCL in the same TU and thus there is a need for different attributes

Yes, your comment idea looks good and helpful to me.
Thanks.

In D118935#3389452, @hvdijk wrote:

It does make sense, then. A slightly more verbose commit message might have helped though :)

That looks good.

In D114025#3140192, @Quuxplusone wrote:

I think "sanity-check" could be reasonably replaced with "smoke-test," but (1) this PR doesn't do that, and (2) the phrase "smoke-test" is probably harder to understand,

In D109609#3006225, @olestrohm wrote:

While it might be possible to extend arbitrarily C++, I have the feeling that having just 1 destructor and having a different code path-code according to the address space could be enough.
It could be possible to write:

In D99190#2659571, @tschuett wrote:

The OMPIRBuilder is the modern version of late outlining:
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
You may consider to go that way with SYCL as well.

In D73967#2653250, @erichkeane wrote:

In D73967#2653044, @erichkeane wrote:

In D73967#2653042, @keryell wrote:

An FPGA programmer is hitting this issue from your unit test:

c++
  signed _ExtInt(1) m; // expected-error{{signed _ExtInt must have a bit size of at least 2}}

Why do you not allow a type able to represent {-1, 0}?

! In D99190#2650326, @bader wrote:

2. I'm looking for suggestions on "OpenCL extensions" clarification.

By looking at this, did we forgot about adding some documentation along what we have for https://clang.llvm.org/docs/ClangOffloadBundler.html ?

Great to have some design documentation!
Just a feedback on the first 20%...

Enabling this feature only with SYCL seems like an easy and quick mitigation, as SYCL compilers downstream can easily update their runtime to the new builtin name.
Otherwise, just removing a feature used for almost 6 months will cause some kind of forking pain...
Anyway, improving the feature and implementation at the same time with an RFC for a wider usage looks like a great idea.

@erichkeane @alexandre.isoard @Naghasan: any feedback in the context of SYCL & HLS C++ about this feature extension?

Great feature for all the weird pieces of hardware all around the world! :-)

Be lazy

The idea of this _ExtInt is to have some extensions.
Since it is an extension, why preventing its use?
For example if I want my 18 bit FPGA BRAM to be accessed atomically?
Or is there an assumption that atomic access can be enabled back with some other mode, such as SYCL or HLS C++?

Adding Tyker (Gauthier Harnisch) because of SYCL similarity

In D75285#1897502, @jeroen.dobbelaere wrote:

I don't think that 'restrict' is a good match for this behavior. For c++, the alias_set proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4150.pdf) would be a better match.

In D73967#1862273, @erichkeane wrote:

At the moment it doesn't work because of parsing. I'm unaware of there is a deeper limitation, but I'll look at it. I was unaware that we allow integral types for _Complex, I'd looked it up on cppreference and only saw the FP types so I was basically just confused as to what your intent was.

Good improvement!

In D61506#1490555, @rsmith wrote:

Per the OpenCL C++ 1.0 specification, section 2:

The OpenCL C++ programming language is based on the ISO/IEC JTC1 SC22 WG21 N 3690 language specification (a.k.a. C++14 specification).

I think it would be reasonable to permit changing the base C++ standard in OpenCL C++ mode

In D61304#1485814, @Anastasia wrote:

In D61304#1485125, @rjmccall wrote:

Presumably a similar rule would apply to thread-locals if you supported them.

We don't support them in OpenCL.

In D60455#1470402, @Anastasia wrote:

In D60455#1470030, @Anastasia wrote:

It would be better to rename clang/test/SemaSYCL/device-attrubutes.cpp to clang/test/SemaSYCL/device-attributes.cpp

While we are thinking about recycling some attributes across languages, we have to think about the fact that real applications are often made from various languages, such as SYCL + OpenMP 5 or whatever.
It would be nice not to forbid such a combination inside the same TU by design.

In D59603#1437684, @Anastasia wrote:

Updated test to use root namespace (commented by Ronan).

I was a little bit worried about

LGTM.

That looks good. Thanks.

In D53705#1285096, @rjmccall wrote:

In D53705#1284268, @rjmccall wrote:

In D53705#1281743, @rjmccall wrote:

In D53705#1278066, @rjmccall wrote:

I don't suppose there's any chance you can just tell Khronos to fix their stuff. It's a little funny to be more conservative about keywords in C++ when the C++ committee is actually much more aggressive about adding keywords in the non-reserved space than C is.

We could submit to the standard an OpenCL C++ extension to accept the OpenCL C syntax...

+1
Please do not remove anything, since it may be useful in some contexts.

Typo