LGTM! Thanks!

LGTM. Thanks!

Use existing diagnostics; add the comment that device can support extension but not the feature. Will follow up if we need explicit mention in the language spec.

There are tests checking for this (e.g. clang/test/Frontend/opencl.cl), so we need this check to preserve the existing behavior indeed.

Rename language mode for device side enqueue builtins; add the comment that device side enqueue builtins are not supported until OpenCL 2.0.

@Anastasia @svenvh ping. Just a kind reminder.

Check only against specific language option, remove unused LanguageIDs

It seems hard to find a direct mention in the spec, but in the API spec:

Reimplement with checking language options only.

Remove no longer required comment in the test.

Add expected-no-diagnostics, fix misprint in test.

Rebase, remove extra 'verify'

Simplified running lines in tests, use 'verify' when validating features, simplify condition in Sema

Now program scope global variables are required by device enqueue in the spec, new patch for device enqueue support: https://reviews.llvm.org/D115640

How about we clarify with Khronos whether it would be sufficient to add a restriction like:

Program scope blocks are only supported when program scope variables feature is supported.

@Anastasia, @yaxunl, do you think it's possible to refactor code generation for blocks such that block literal for global blocks (with no captures) would be emitted in constant address space? Now it's emitted in global address space (for example @__block_literal_global in https://godbolt.org/z/4z8hGj7hz).

LGTM, thanks!

Yeah, this looks good. Thanks! Please notify when this is ready to land.

Restore original test name which was changed in D106748, use check-prefixes

We might need to fix the target triple in clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl to avoid surprises with testing but it has better coverage if we don't though...

@airlied, can you please fix that to something like here https://godbolt.org/z/3Kbso8ca3? What currently we do have with your patch is that generic address space overload is always selected, but more strict overloading always exist in OpenCL C 3.0 (https://godbolt.org/z/vbMrdMxs1).

Fix doubling run lines, misprint

Reverted it due too suspicious failing:

error: 'error' diagnostics expected but not seen: 
  File /home/tcwg-buildslave/worker/clang-armv7-2stage/llvm/clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl Line 8: type '__global write_only pipe int ({{(void)?}})' can only be used as a function parameter in OpenCL
error: 'error' diagnostics seen but not expected: 
  File /home/tcwg-buildslave/worker/clang-armv7-2stage/llvm/clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl Line 8: type '__private write_only pipe int (void)' can only be used as a function parameter in OpenCL
2 errors generated.

Rebase

Preserve existing diagnostic with err_opencl_unknown_type_specifier, fix comments for language option

Unify with err_opencl_requires_extension. Infrastructure for getting aliased extensions seems to messy and doesn't seem worth it yet since there are only two cases of such functionality (fp64 and 3d image writes) :(

You also need to guard memory_order_seq_cst enum entry. Note that memory_order_acq_rel is always defined as it can be used in atomic_work_item_fence() built-in function, AFAIR in all other cases if memory_order_acq_rel is used without __opencl_c_atomic_order_acq_rel feature it is undefined behavior.

Change diagnostic output

Restructured test a little

Add comment for C++ for OpenCL, add variable to check support for OpenCL C

Update test after generic AS was merged

Fixed naming of new methods, fixed comments, removed redundant comments from source file

Fixed latest comment about checking for == 300. Btw, there already exists a few places where >= 300 is checked. Should fix them as well.

Added FIXME. Alternatively, we could add this language option only in ::adjust if there is still a worry about multiple places of definitions. Btw, there will some more language options which dependent on target settings for OpenCL C 3.0, such as pipes and blocks

Addressed latest review comments, also refactored the patch by putting diagnostics into OpenCLOptions

Restructured test, added comments

Set SPIR target for added test

Thanks for working on this! That's cool, I managed to reproduce something similar to https://reviews.llvm.org/D99577.

In D97869#2807654, @svenvh wrote:

In D97869#2807627, @azabaznov wrote:

@svenvh, are you going to add header-like output emitting?

Yes, I can add that if there is interest. I already have it on a local branch, so if there is interest (and it seems there is? :-)), then I will rebase that, tidy it up, and create a separate review.

@svenvh, are you going to add header-like output emitting?