In clu_runtime.cpp in the binary version of CLU_Runtime::BuildProgram there is a bug, if in_numBinaries >= m_numDevices. In this case pLengths and pBinaries will be NULL, which are passed to clCreateProgramWithBinary.

It seems that a else branch is missing in line 693.

Since the arguments all get converted to size_t when creating the return value, it might as well take them as size_t, which would also avoid truncation issues if someone passes a value outside the range of int.

The spec says all the members are cl_uint, but in reality the array members are size_t.

can you post the build info or makefile for macos?

When compiling under gcc the following errors occur:

clu_runtime.cpp: In constructor ‘DeviceTypeToId::DeviceTypeToId()’:
clu_runtime.cpp:137:47: error: ‘memset’ was not declared in this scope
clu_runtime.cpp: At global scope:
clu_runtime.cpp:260:1: error: specializing member ‘CLU_Runtime::CLU_Specific<cl_context>::~ CLU_Runtime::CLU_Specific<cl_context>’ requires ‘template<>’ syntax
clu_runtime.cpp:261:1: error: specializing member ‘CLU_Runtime::CLU_Specific<cl_command_queue>::~ CLU_Runtime::CLU_Specific<cl_command_queue>’ requires ‘template<>’ syntax
clu_runtime.cpp:262:1: error: specializing member ‘CLU_Runtime::CLU_Specific<cl_program>::~ CLU_Runtime::CLU_Specific<cl_program>’ requires ‘template<>’ syntax
clu_runtime.cpp: In member function ‘void CLU_Runtime::Reset()’:
clu_runtime.cpp:287:53: error: ‘memset’ was not declared in this scope
clu_runtime.cpp: In function ‘cl_platform_id* GetPlatformByVendor(cl_uint, cl_platform_id* const, const char, cl_int_)’:
clu_runtime.cpp:362:42: error: ‘strstr’ was not declared in this scope
clu_runtime.cpp: In function ‘cl_program cluBuildSourceArray(cl_uint, const char**, const char_, cl_int_)’:
clu_runtime.cpp:832:92: error: ‘strlen’ was not declared in this scope
clu_runtime.cpp:832:93: error: ‘strncmp’ was not declared in this scope
clu_runtime.cpp: In function ‘const char* CLU_GetDeviceInfo(cl_int*)’:
clu_runtime.cpp:1105:90: warning: passing NULL to non-pointer argument 3 of ‘cl_int clGetDeviceIDs(cl_platform_id, cl_device_type, cl_uint, _cl_device_id**, cl_uint*)’ [-Wconversion-null]

The errors related to memset, strlen, strncmp, etc. can be fixed by including cstring:

include

The errors on line 260, 261 and 262 can be fixed by following the compiler's suggestion:

template<>
CLU_Runtime::CLU_Specific<cl_context>::~CLU_Specific() {clReleaseContext(m_o);}

template<>
CLU_Runtime::CLU_Specific<cl_command_queue>::~CLU_Specific() {clReleaseCommandQueue(m_o);}

template<>
CLU_Runtime::CLU_Specific<cl_program>::~CLU_Specific() {clReleaseProgram(m_o);}

Finally, the warning can be dealt with by converting the NULL to a 0:

status = clGetDeviceIDs(platforms[i], CL_DEVICE_TYPE_ALL, 0, NULL, &numDevices);

Would be nice to query the properties of a specific device. E.g. use query to find a device that supports a specific extension, then initialize clu to use that device by default. Or start up CLU, then query the properties of the devices it picked for the default context.

APIs are implemented but not documented.

Only cluBuildSourceArray() offers a compile_options parameter, which forces the user to manually read a .cl-file in case she wants to specify compiler options. To my experience, the latter is very common to pass defines for code configuration and compile-time arguments.

If whoever is responsible for that decision agrees, I would happily deliver the changes as a pull request.

The following line:

https://github.com/Computing-Language-Utility/CLU/blob/master/clu_runtime/clu_runtime.cpp#L1333

makes the library incompatible with OpenCL 1.1, which basically means it doesn't work with Nvidia's OpenCL implementation shipped with the CUDA SDK.

Putting a macro called INLINE into the macro namespace has potential to clash with any other package (or user's code) that wants to do the same thing. It should be named CLU_INLINE or something like that.

C99 has different semantics from C++ for inline functions. This causes Clang to generate link errors. See http://clang.llvm.org/compatibility.html#inline for more explanation.

The simplest fix is probably to change the inline functions to static inline. Alternatively, the inline functions in clu.h could have out-of-line implementations in clu_runtime.c - but that would need some verification to check that this works under all the flavours of inlining (C99, gnu89, C++, MSVC's not-quite-C compiler).

Note that this affects both clu.h and the code generated by clu_generator.