Once of the changes in the generated headers PR (KhronosGroup/OpenCL-Headers#161) is to add a #define for each of the extensions in the headers unconditionally. Previously, this was done inconsistently and only for some extensions.
This change will cause several places in the CTS tests that declare variables or structure fields using unmodified extension names to pick up the value of the define, which is almost certainly not the intended behavior and usually results in an odd build error.
A few of the places I have found are:
- The
computeinfo test has an "extensions" structure with cl_khr_fp64 and cl_khr_fp16 fields.
- The
spir test has a "ClKhrs" enum with lots of extension names.
- Note that this enum already has encountered this problem for
cl_khr_gl_sharing and cl_khr_icd.
We should think about how to solve this problem before merging the generated headers PR. Two possible solutions are: Use a different name such as one with a prefix or suffix (e.g. has_cl_khr_some_extension), or to #undef the symbols as is done in the current spir test.
Once of the changes in the generated headers PR (KhronosGroup/OpenCL-Headers#161) is to add a
#definefor each of the extensions in the headers unconditionally. Previously, this was done inconsistently and only for some extensions.This change will cause several places in the CTS tests that declare variables or structure fields using unmodified extension names to pick up the value of the define, which is almost certainly not the intended behavior and usually results in an odd build error.
A few of the places I have found are:
computeinfotest has an "extensions" structure withcl_khr_fp64andcl_khr_fp16fields.spirtest has a "ClKhrs" enum with lots of extension names.cl_khr_gl_sharingandcl_khr_icd.We should think about how to solve this problem before merging the generated headers PR. Two possible solutions are: Use a different name such as one with a prefix or suffix (e.g.
has_cl_khr_some_extension), or to#undefthe symbols as is done in the currentspirtest.