cl.h currently includes error codes for:

• CL_INVALID_GL_OBJECT
• CL_INVALID_MIP_LEVEL

These error codes are defined by extensions though, and are not in the core API specification.

Questions are:

• Should they be in cl_ext.h instead?
• Should they have a KHR suffix?

<cl_platform.h> defines some standard mathematical constants, in both single- and double-precision formats:

$ ( sed -n '/stdint/,$p' | grep 'CL_M_' ) <cl_platform.h

#define  CL_M_E             2.718281828459045090796
#define  CL_M_LOG2E         1.442695040888963387005
#define  CL_M_LOG10E        0.434294481903251816668
#define  CL_M_LN2           0.693147180559945286227
#define  CL_M_LN10          2.302585092994045901094
#define  CL_M_PI            3.141592653589793115998
#define  CL_M_PI_2          1.570796326794896557999
#define  CL_M_PI_4          0.785398163397448278999
#define  CL_M_1_PI          0.318309886183790691216
#define  CL_M_2_PI          0.636619772367581382433
#define  CL_M_2_SQRTPI      1.128379167095512558561
#define  CL_M_SQRT2         1.414213562373095145475
#define  CL_M_SQRT1_2       0.707106781186547572737
#define  CL_M_E_F           2.71828174591064f
#define  CL_M_LOG2E_F       1.44269502162933f
#define  CL_M_LOG10E_F      0.43429449200630f
#define  CL_M_LN2_F         0.69314718246460f
#define  CL_M_LN10_F        2.30258512496948f
#define  CL_M_PI_F          3.14159274101257f
#define  CL_M_PI_2_F        1.57079637050629f
#define  CL_M_PI_4_F        0.78539818525314f
#define  CL_M_1_PI_F        0.31830987334251f
#define  CL_M_2_PI_F        0.63661974668503f
#define  CL_M_2_SQRTPI_F    1.12837922573090f
#define  CL_M_SQRT2_F       1.41421353816986f
#define  CL_M_SQRT1_2_F     0.70710676908493f

Bizarrely, the single- and double-precision versions DO NOT MATCH BEYOND THE SEVENTH DIGIT:

$ ( sed -n '/stdint/,$p' | grep 'CL_M_' ) <cl_platform.h |
    ( sort | sed -r -e 's/ 0\./0./' -e 's/(.{36})(.*)/\1 \2/' )

#define  CL_M_1_PI         0.3183098 86183790691216
#define  CL_M_1_PI_F       0.3183098 7334251f

#define  CL_M_2_PI         0.6366197 72367581382433
#define  CL_M_2_PI_F       0.6366197 4668503f

#define  CL_M_2_SQRTPI      1.128379 167095512558561
#define  CL_M_2_SQRTPI_F    1.128379 22573090f

#define  CL_M_E             2.718281 828459045090796
#define  CL_M_E_F           2.718281 74591064f

#define  CL_M_LN10          2.302585 092994045901094
#define  CL_M_LN10_F        2.302585 12496948f

#define  CL_M_LN2          0.6931471 80559945286227
#define  CL_M_LN2_F        0.6931471 8246460f

#define  CL_M_LOG10E       0.4342944 81903251816668
#define  CL_M_LOG10E_F     0.4342944 9200630f

#define  CL_M_LOG2E         1.442695 040888963387005
#define  CL_M_LOG2E_F       1.442695 02162933f

#define  CL_M_PI_2          1.570796 326794896557999
#define  CL_M_PI_2_F        1.570796 37050629f

#define  CL_M_PI            3.141592 653589793115998
#define  CL_M_PI_F          3.141592 74101257f    /* re-ordered */

#define  CL_M_PI_4         0.7853981 63397448278999
#define  CL_M_PI_4_F       0.7853981 8525314f

#define  CL_M_SQRT1_2      0.7071067 81186547572737
#define  CL_M_SQRT1_2_F    0.7071067 6908493f

#define  CL_M_SQRT2         1.414213 562373095145475
#define  CL_M_SQRT2_F       1.414213 53816986f

THEY CAN'T BOTH BE CORRECT!

The situation may not be as bad as it looks -- the double-precision values may be entirely correct, and since eight decimal digits would be sufficient to represent the 24-bit mantissa of the single-precision values, their inaccuracy may be very small. But it looks quite odd, and is likely to cause problems if these definitions are ever copied and reused somewhere else.

Surely this should be investigated?

In KhronosGroup/OpenCL-Registry#55 I have a reference page fix to match the 2.2 extension spec, which adds a missing _KHR suffix to several tokens introduced by the mipmap extension. The suffix also appears to be missing from (all of) the headers in this repo. If the spec is taken as the controlling document, we should probably add aliases of the non-suffixed tokens with the suffix added, and maybe acknowledge somewhere (ref pages? extension spec?) that the non-suffixed versions were an error.

cl_half is currently defined as a 16-bit integer, which allows code that might appear to assign floating point values to a cl_half to compile and give the wrong result.

Issue #102 will allow automatic conversion between cl_half and float in C++, but this will mean that C++ code that does not include the <CL/cl_half.h> header and code which is backported to C will be at risk of performing assignments without the expected conversion between floating point and integer formats.

This is fixable by defining cl_half as a struct or union containing a single 16-bit integer member.

See discussions on #57 and #60

I tried to compile some code with latest headers (from HEAD) using x86_64-w64-mingw32-g++ 7.4.0 crosscompiler shipped with Cygwin. I got following errors:

In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/intrin.h:41:0,
                 from ./CL/cl_platform.h:380,
                 from ./CL/cl.h:35,
                 from ./CL/opencl.h:47,
                 from CL/cl.hpp:170,
                 from RakeSearchOpenCL.h:6,
                 from main.cpp:19:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1848:42: error: macro "__cpuid" requires 5 arguments, but only 2 given
 void __cpuid(int CPUInfo[4], int InfoType);
                                          ^
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1851:42: error: macro "__cpuid" requires 5 arguments, but only 2 given
 void __cpuid(int CPUInfo[4], int InfoType) {
                                          ^
In file included from ./CL/cl_platform.h:380:0,
                 from ./CL/cl.h:35,
                 from ./CL/opencl.h:47,
                 from CL/cl.hpp:170,
                 from RakeSearchOpenCL.h:6,
                 from main.cpp:19:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/intrin.h:1117:44: error: macro "__cpuid" requires 5 arguments, but only 2 given
     __MACHINEI(void __cpuid(int a[4],int b))
                                            ^
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/intrin.h:41:0,
                 from ./CL/cl_platform.h:380,
                 from ./CL/cl.h:35,
                 from ./CL/opencl.h:47,
                 from CL/cl.hpp:170,
                 from RakeSearchOpenCL.h:6,
                 from main.cpp:19:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1848:6: error: variable or field ‘__cpuid’ declared void
 void __cpuid(int CPUInfo[4], int InfoType);
      ^~~~~~~
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1851:6: error: variable or field ‘__cpuid’ declared void
 void __cpuid(int CPUInfo[4], int InfoType) {
      ^~~~~~~
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1852:4: error: expected primary-expression before ‘__asm__’
    __asm__ __volatile__ (
    ^~~~~~~
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1852:4: error: expected ‘}’ before ‘__asm__’
In file included from ./CL/cl_platform.h:380:0,
                 from ./CL/cl.h:35,
                 from ./CL/opencl.h:47,
                 from CL/cl.hpp:170,
                 from RakeSearchOpenCL.h:6,
                 from main.cpp:19:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/intrin.h:1117:5: error: variable or field ‘__cpuid’ declared void
     __MACHINEI(void __cpuid(int a[4],int b))
     ^
In file included from CL/cl.hpp:170:0,
                 from RakeSearchOpenCL.h:6,
                 from main.cpp:19:
./CL/opencl.h:55:1: error: expected declaration before ‘}’ token
 }

Problem is caused by following part of code in cl_platform.h

    #if defined( __MINGW64__ )
        #include <intrin.h>
    #else
        #include <xmmintrin.h>
    #endif

There are 3 similar code clocks there. When I commented out parts for __MINGW64__ , code compiled without errors.

I use SSE/AVX intrinsics for more than 2 years, and during that time I always included headers as suggested in Intel Intrinsics Guide. Looks that MinGW shipped with Cygwin has correct headers and does not need any workarounds. If you need them for some other reason, some extra checks will be needed here.

The headers are using a number of identifiers that are reserved in C/C++ (e.g. those beginning with __, see https://en.cppreference.com/w/c/language/identifier). We should rename all of these.

in the cl.h file:

CL_KERNEL_MAX_NUM_SUB_GROUPS
CL_KERNEL_COMPILE_NUM_SUB_GROUPS

are attributed to cl_kernel_info whereas they are cl_kernel_sub_group_info (see clGetKernelSubGroupInfo).

The current OpenCL headers include argument names, but only within comments:

extern CL_API_ENTRY cl_int CL_API_CALL
clGetPlatformIDs(cl_uint          /* num_entries */,
                 cl_platform_id * /* platforms */,
                 cl_uint *        /* num_platforms */) CL_API_SUFFIX__VERSION_1_0

This prevents the argument names from appearing in some IDE features, such as Intellisense.

Is there a reason for this, or can the argument names be un-commented?

extern CL_API_ENTRY cl_int CL_API_CALL
clGetPlatformIDs(cl_uint          num_entries,
                 cl_platform_id * platforms,
                 cl_uint *        num_platforms) CL_API_SUFFIX__VERSION_1_0;

The defines for the minimum and maximum cl_short values are defined as:

#define CL_SHRT_MAX         32767
#define CL_SHRT_MIN         (-32767-1)
#define CL_USHRT_MAX        65535

https://github.com/KhronosGroup/OpenCL-Headers/blob/master/CL/cl_platform.h#L190

In the spec, they are spelled out as "SHORT" completely. I think the headers should be updated to match the spec.

See KhronosGroup/OpenCL-Docs#351

I think we should be able to do cl_float4.x with -std=c11, as we currently are with -std=gnu99

Just need to patch line

#if defined( __GNUC__) && ! defined( __STRICT_ANSI__ )

to also check for C11.

See also: http://stackoverflow.com/questions/10979487/opencl-cl-datatypes-arithmetic

Supposing of course CL headers will support c11.

I've just noticed that this repository is using an MIT license, whereas most of our others use Apache 2.0. The new test files that I added recently (copied from CTS) use Apache 2.0, which doesn't match the MIT license specified in the root LICENSE file in this repository.

IANAL, so I don't know if this matters and/or what we should do about it, so opening this issue just to check with others. Can we change either the licenses for the new tests or the licenses for the headers themselves? Should we just add the Apache 2.0 license text to the root LICENSE file? Or do nothing since the test sources were originally released under Apache 2.0 before being copied here?

Apparently I have just opened my first PR on this repository, so I need to file the CLA. No problem, but it says

All contributions to this repository are made under the MIT License. You may obtain a copy of the License at https://opensource.org/licenses/MIT. Each contributor represents and warrants, on behalf of their employer or other principal if they are acting within the scope of their employment or otherwise as the agent of a legal entity, that they have the right and authority to make their contribution under these terms.

And then quotes the full MIT license.

This is out of date, the license was recently changed to Apache 2.0: #76

Currently OpenCL headers are versioned based on the OpenCL spec (1.2, 2.0, 2.2 etc)

Apart from the core and optional core features that we change only with OpenCL version, we often add types and APIs required by KHR extensions in some of the standard headers (e.g. clext.h). Sometimes, the extension might be written on top of 1.2 or 2.0.

Current versioning doesn't allow differentiating between the OpenCL headers before and after such changes. Having finer versioning may help recommend right version of headers users need to use and potentially clarify this dependency in the extension specs.

Filing this issue to discuss pros and cons of adding the finer versioning.

Hello,

Please I am trying to use this headers for a project I am working on, and building my system based on the Alpine docker image. I have noticed that the opencl headers are kind of old built (like2016). IS there any way please I can build the latest one myself locally? ALl I need is the command line.

Kind regards

The policy for extension preprocessor defines - meaning a #define for cl_my_extension_name in the headers - is currently a bit ad-hoc. It looks like the original intent was that an extension should have a define if it adds new API functions, but not otherwise, e.g.:

/* cl_khr_fp64 extension - no extension #define since it has no functions  */

But, some extensions include a define anyways, either because they erroneously included a define initially and this has been carried forward for backwards compatibility, or because an extension define can be useful even when it doesn't add new API functions - see #85 and KhronosGroup/OpenCL-CLHPP#82.

Should we just add an extension define in all cases, uniformly?

There are a number of so-called "headers" tests in the CTS (https://github.com/KhronosGroup/OpenCL-CTS/tree/master/test_conformance/headers) that don't really test the OpenCL implementation itself but rather whether the headers build cleanly using the target toolchain and whether some aspects of them behave correctly.

I think these tests should be moved to the headers repo as they're effectively testing the headers in isolation. However, I still see value in requiring that these tests pass on a platform for which OpenCL compliance is sought. Maybe this can be a requirement of the conformance process?

Any opinions?

The CL_CONTEXT_TERMINATED_KHR error code is not defined in any header file.

One of our engineers reported an issue in the OpenCL headers recently regarding signed and unsigned mismatch compiler warnings in some cases with modern compilers at higher warning levels. The crux of the issue is that many of the OpenCL types are unsigned, e.g.:

typedef cl_uint             cl_command_type;

But, the corresponding enums are signed, e.g.:

/* cl_command_type */
#define CL_COMMAND_NDRANGE_KERNEL                   0x11F0
#define CL_COMMAND_TASK                             0x11F1
#define CL_COMMAND_NATIVE_KERNEL                    0x11F2
...

This can lead to an error in code like the following (see godbolt example here):

#define MY_VALUE 0x10

template <typename T1, typename T2>
bool is_eq(const T1& lhs, const T2& rhs) {
    if (lhs == rhs) {
        return true;
    }
    return false;
}

void f() {
    unsigned x = 2;
    is_eq(x, MY_VALUE);
}

This seems like a rather narrow use-case, but it's actually fairly common in googletest unit tests:

const cl_command_type command_type;
clGetEventInfo(event, CL_EVENT_COMMAND_TYPE, sizeof(command_type), &command_type, nullptr);
EXPECT_EQ(CL_COMMAND_TYPE_NDRANGE_KERNEL, command_type);

Should we define most OpenCL enums - all but error codes I think? - as explicitly unsigned? I don't think this will break existing code, and it will fix this compile warning:

/* cl_command_type */
#define CL_COMMAND_NDRANGE_KERNEL                   0x11F0u
#define CL_COMMAND_TASK                             0x11F1u
#define CL_COMMAND_NATIVE_KERNEL                    0x11F2u
...

In the OpenCL 2.1 headers, the type definition of cl_kernel_sub_group_info is performed twice:

1. Line 97 of cl.h
2. Line 323 of cl_ext.h

This causes a warning when compiling with clang (3.6/3.8):

./ocl/2.1/CL/cl_ext.h:323:18: warning: redefinition of typedef 'cl_kernel_sub_group_info' is a C11 feature
      [-Wtypedef-redefinition]
typedef cl_uint  cl_kernel_sub_group_info;
                 ^
./ocl/2.1/CL/cl.h:97:29: note: previous definition is here
typedef cl_uint             cl_kernel_sub_group_info;

Hi,

where can I find a header for cl_nv_d3d11_sharing and why isn't it included here?

At the head of the file it comments

cl_gl_ext.h contains vendor (non-KHR) OpenCL extensions which have OpenGL dependencies.

This is followed by the KHR, non-vendor extension cl_khr_gl_event. So, documentation inconsistent with contents. Perhaps the comment should be altered to "contains OpenCL extensions which have OpenGL dependencies"? Or the extension interface moved to cl_gl.h?

Any plans to tag releases of the OpenCL headers on Github, as it is now done for OpenCL-CLHPP?

Thanks,

We currently provide no host-side support for converting between cl_half and other integer or floating-point types.

The following code snippet

cl_float myfloat = ...
cl_half myhalf = (cl_half)myfloat;

results in a floating-point to integer conversion. This is really not nice.

While we can't make the above work in applications written in C, I suggest we provide conversion routines like https://github.com/KhronosGroup/OpenCL-CTS/blob/master/test_common/harness/imageHelpers.cpp#L898 as part of the headers. For applications written in C++, we could make casts work automatically.

I'm a little confused by the prefix and suffix pre-processor defines for deprecated OpenCL APIs. I believe this is a summary of what is in the headers currently:

Should the define indicate:

• When the API was added?
• When the API was last supported?
• When the API was deprecated?
• Or something else entirely?

Right now it looks like we have a bit of a mix, though it looks like we have more usage of "last supported" than anything else.

I'm looking at this to ensure that if we deprecate clSetProgramReleaseCallback we do it consistently. Thanks!

The 3.0 specification added a new API entry point, this should be added to the headers.

KhronosGroup/OpenCL-Docs#346

We haven't documented which compilers and compiler options including C and C++ standard versions the headers support, which makes it difficult to determine if issues like #115 and #121 are header issues or unsupported configurations. We should document (and test for!) the compilers and compiler options we're intending to support and be clear that other configurations may not work or have limitations.

FWIW, there is a similar issue already for the C++ bindings:
KhronosGroup/OpenCL-CLHPP#78

Hi, For documentation purpose and project release process we need the Export control classification number(ECCN) for Opencl if it applies. Can you please let me know the ECCN ?

I'm mostly raising this issue for awareness and to avoid duplicated work.

I started experimenting with generated extension headers using the cl.xml file over the weekend and I'm pretty close to having something workable. In addition to the nice consistency benefits, this also provides a mechanism to validate that the XML file is correct for extensions, and enables easy additions for things like a symbolic name for extensions (#111) and preprocessor defines for extensions (#86).

Note that I've only done extension headers for now, and not the core API headers. The extension headers were easier (fewer conditional rules) and are faster moving, so I think they provide a bigger bang-for-the-buck, and I don't plan to generate the core API headers at this time.

The few issues I still need to resolve are:

• What should we do for the extensions that require external headers, such as the GL, EGL, and DX extensions? It's easy enough to omit them from the final generated headers, or we could consider a way to describe these extensions without external header dependencies. (I know how to do this mostly - PR soon.)
• The Intel extensions are in their own file with a unique copyright header. I'll look into this. (Fixed by #129).
• I need to figure out how to add the special-case handling for CL_DEVICE_DOUBLE_FP_CONFIG (only for pre-OpenCL 1.2) and cl_kernel_sub_group_info (only for pre-OpenCL 2.1). (See KhronosGroup/OpenCL-Docs#463, KhronosGroup/OpenCL-Docs#469)
• It looks like the macros for cl_khr_extended_versioning are not in the XML file, so they need to be added and I need to figure out how to properly generate code for them. (I know how to do this - PR soon.)
• Decide what to do with cl_gl_ext.h (see #145, fixed by #156).
• Ensure extension API prefix and suffixes are correct and consistent (see #153, #158).

Currently to pass builds cleanly, warning-free we have to disable format-related warnings. We should consider fixing those.

While making the changes in #41 I noticed that we do not currently define enums for cl_khr_image2d_from_buffer in cl_ext.h. Instead, the enums for this extension are in cl.h, protected by #ifdef CL_VERSION_1_2, and do not have the KHR suffix. This doesn't seem correct.

One solution is to add suffixed versions of the enums to cl_ext.h, similar to what was done in #33 for the mipmap extension. Note however, the extensions doc currently does not include a KHR suffix on the enums, so this may not be the right thing to do in this case.

Alternatively, we could add the un-suffixed enums to cl_ext.h if they aren't defined in cl.h, similar to what was done for subgroups (see #2). This solution preserves source backwards compatibility.

CL_API_SUFFIX__VERSION_2_X macros aren't defined by cl_platform.h when __APPLE__ is present. This seems like an arbitrary limitation.

According to https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_device_attribute_query.txt

Lots of defines have been added as part of cl_amd_device_attribute_query, but I did't find them in the cl_ext.h.

only the first one is avaliable right now.

I'm not sure how else to contact Khronos regarding this but perhaps here will work. I was looking at all the headers on the Khronos website and noticed that for every cl.hpp file prior to OpenCL 2.0 they are all pointing to https://www.khronos.org/registry/cl/api/2.1/cl.hpp.

Is that the intention or has there been a mistake? It just seemed odd to me that if a user needed OpenCL 1.1 headers and the link is taking them to the 2.1 API.

The CL_DBL_MAX definition results in a 311 character long literal double. When used, the preprocessor expands CL_DBL_MAX and the resulting identifier is too long for Visual Studio 2013 resulting in the following compiler error.

fatal error C1064: compiler limit : token overflowed internal buffer

Looking into this error further the only solution provided on MSDN is this.

compiler limit : token overflowed internal buffer

An identifier exceeds the length of the internal buffer used for identifiers. Shorten the name.

This is not a problem in Visual Studio 2015 but the headers should still compile with older versions of Microsoft's compiler.

My recommendation is to revert to the current definition, in both places, to previous definition of CL_DBL_MAX, and ensure to apply the fix to all branches in this repository.

#define CL_DBL_MAX          1.7976931348623158e+308

This applies to all of the branches is this repository, I've created a new issue since this is a compiler error but it seems it may be related to #17.

I guess this is the same issue as was the case with GCC inside typedef struct _cl_image_desc for eg. which was circumvented with the code:

#ifdef __GNUC__
    __extension__   /* Prevents warnings about anonymous union in -pedantic builds */
#endif
    union {
      cl_mem                  buffer;
      cl_mem                  mem_object;
    };

MSVC has exactly the same problem when compiled with /Za, strict ANSI conformance.

We still need to add support in the headers for CL_HAS_NAMED_RGBA_VECTOR_FIELDS which we added in OpenCL 3.0.

See: Named vector components notation

See KhronosGroup/OpenCL-Docs#338

This is caused by PR #116

Minimal reproducer:

// test.cpp
#include <CL/cl.h>

int main() {
  cl_image_desc image_desc;
  (void)image_desc.mem_object;
  return 0;
}

Then compile with

g++ -I$(pwd) -std=c++14 test.cpp

Error:

note: #pragma message: cl_version.h: CL_TARGET_OPENCL_VERSION is not defined. Defaulting to 220 (OpenCL 2.2)
test.cpp: In function ‘int main()’:
test.cpp:6:20: error: ‘cl_image_desc’ {aka ‘struct _cl_image_desc’} has no member named ‘mem_object’
   (void)image_desc.mem_object;
                    ^~~~~~~~~~

We have tests for many of the header files in this repo, but we're missing testing for cl_d3d10.h, cl_d3d11.h, and cl_dx9_media_sharing.h.

Vulkan provides preprocessor macros (e.g. VK_KHR_SURFACE_EXTENSION_NAME defined as "VK_KHR_surface"). This helps with avoiding typos in extension names that can lead to silly bugs. We should do the same. These definitions could be generated automatically from the XML.

When compiling an empty main including cl.h the compiler bails out on anonymous structs when compiling in strict ANSI conformance using the /Za flag. This compiler option also defines __STDC__ which can be used to detect such use cases and be added to L487 of cl_platform.h to read:

#elif defined( _WIN32) && defined(_MSC_VER) && ! defined(__STDC__)

This issue is here for me to remember ro open a PR and what the issue is (since I got to the bottom of it).

See:

KhronosGroup/OpenCL-Docs#284
KhronosGroup/OpenCL-Docs#458

It looks like the enums for depth images in the headers have a similar problem:

#ifdef CL_VERSION_1_2
#define CL_DEPTH                                    0x10BD
#define CL_DEPTH_STENCIL                            0x10BE
#endif

We should:

• Move some of these enums out of OpenCL 1.2 and into OpenCL 2.0 in cl.h, since this is when they became a core feature.
• Move / duplicate a few other enums into cl_ext.h, since they are extension enums and are not part of a core API.

opencl22/CL/cl.h:538

s/cl_kernel_arg_type_qualifer/cl_kernel_arg_type_qualifier/

The current and only tag v2020.03.13 gives a compiler error in the ICD-loader repository with the same release version. A bugfix was pushed two weeks later, but that forces me 'subscribe' to both master branches again, but that gives instabilities in my project that uses them.
Could you please add a new release/tag to improve stability in downstream projects? Thanks

We're not currently providing releases of the headers. This makes a number of things like integrating them into Linux distributions a bit challenging. It seems we got a request in the past that was closed without replying or providing a solution (#11). (cc @ghisvail, @vdanjean).

I suggest we use a date-based tagging scheme (e.g. YYYY-MM) to avoid the confusion with OpenCL versions.

At least cl_icd.h has got issues on Windows (it's not self-contained). We should add CI on Windows and fix existing errors. Extending the existing Travis CI config should work.

Hi,
The documentation lists the CL_VERSION_X_Y preprocessor defines as corresponding to the integer XY0, but all the examples I can find in cl.h for various versions in this repo define it as 1, e.g. in the 2.2 headers

Am I missing something?