KhronosGroup / OpenCL-Headers

Khronos OpenCL-Headers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[OpenCL 2.0][cl.h with C++] struct `cl_image_desc` is missing field `mem_object`

Nuullll opened this issue · comments

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;
                    ^~~~~~~~~~

Reverting the change on cl.h could fix this issue.
Explained here: #116 (comment)

I don't think we should completely revert the change to cl.h because there are some situations where anonymous structs and unions are not supported.

I do wonder though if we should be trying to identify these cases where anonymous structs and unions ARE NOT supported to skip them vs. trying to identify the cases where anonymous structs and unions ARE supported to enable them. In other words, flip the conditions so anonymous structs and unions are supported by default, since this is likely to be a more common case (and an easier fix for the compilers that do not support anonymous structs and unions).

Note, I think we also need to differentiate between anonymous structs and anonymous unions:

https://stackoverflow.com/questions/12355118/which-standards-allow-anonymous-structs-and-unions-in-c-and-c/12355215

Anonymous unions are supported more broadly than anonymous structs.

Thanks! @bashbaug
Differentiating anonymous structs/unions and flipping the condition sounds to be a decent solution.

I'm also wondering what should the expected behavior be when anonymous structs/unions are not supported. Say we are compiling OpenCL 2.0 application codes using MS C compiler with the /Za option, where MS extensions to ANSI C89/ISO C90 are disabled so that anonymous unions are not supported. Then:

  • should we discard OpenCL 1.2 backward compatibility, since we can not support cl_image_desc.buffer and cl_image_desc.mem_object at the same time?
  • or should we require users to change the compiler flags or upgrade the compiler itself?

I created PR #125 that I believe implements the changes described above. In practice, this meant reverting the previous change to cl.h and then adding a condition specifically for MSVC and /Za, since this is where anonymous unions are known to be unsupported. Please take a look and see if this works for you.

Regarding behavior when anonymous unions are not supported, this is a good question. For now we've prioritized keeping backward compatibility with OpenCL 1.2 source, which means we've kept image_desc.buffer instead of image_desc.mem_object, but we could just as easily go the other way around. I don't think there's a clear right answer. Hopefully this rarely happens, since most compilers should support anonymous unions!