Not all OpenCL extensions are disabled by default

[llvmbot]

Bugzilla Link	47882
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@AnastasiaStulova

Extended Description

The OpenCL specification requires implementation to disable all extensions by default. This implies that using any builtin functions from an extension should produce a compile-time error.

Clang doesn't respect this rules, at least not for all extensions as the following example shows:

unsigned int foo() { return get_sub_group_size(); }

This code compiles (while it should not) when using opencl-c.h and doesn't (as expected) when using -fdeclare-opencl-builtins.

https://godbolt.org/z/WrMsMj

For reference, see the specification https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_Ext.html#compiler-directives-for-optional-extensions

[llvmbot]

For OpenCL 1.0, the following extensions do no require pragma directive when they should according to the spec:

• cl_khr_byte_addressable_store
• cl_khr_global_int32_base_atomics, cl_khr_global_int32_extended_atomics, cl_khr_local_int32_base_atomics, cl_khr_local_int32_extended_atomics
• cl_khr_int64_base_atomics

[llvmbot]

I looked at the values returned by clang::OpenCLOptions::isEnabled for each extension supported by Clang and found out that:

• cl_khr_fp64 is enabled by default with OpenCL 1.2 and later. It should however always be disabled by default.
• cl_khr_3d_image_writes is enabled by default with OpenCL 2.0 and 3.0. But it is optional in OpenCL 3.0 and therefore should be disabled by default for that version of the language; it is a core feature only in OpenCL 2.0.

Furthermore, for the following extensions Clang does not require a #pragma directive when it should (i.e. BIFs/types are available/usable by default):

• cl_khr_int64_base_atomics (all versions from 1.1 to 3.0)
• cl_khr_depth_images (1.1-1.2)
• cl_khr_mipmap_image (2.0 and 3.0)
• cl_khr_mipmap_image_writes (2.0 and 3.0)
• cl_khr_subgroups (2.0 and 3.0)
• cl_khr_fp64 and cl_khr_3d_image_writes as described above.

I'm not sure how cl_khr_srgb_image_writes should behave and therefore be tested.