rsmith added a comment. In https://reviews.llvm.org/D53153#1263848, @scott.linder wrote:
> Beyond constructors/destructors I believe an API which we implement through > access to dynamic symbols for global variable is `clGetProgramBuildInfo(..., > CL_PROGRAM_BUILD_GLOBAL_VARIABLE_TOTAL_SIZE, ...)` which is defined as "The > total amount of storage, in bytes, used by program variables in the global > address space." Presumably this is looking at the size of a certain section / segment of the image. It's unclear to me why symbol visibility would affect this in any way. > As for kernels, an example of an API which we implement through access to > kernel symbols is `clGetProgramInfo(..., CL_PROGRAM_KERNEL_NAMES, ...)` Sure. `kernel`, like `dllexport` or `visibility(default)`, seems to act as declaring a function to be part of the external interface of the code, and it makes sense for all of those to override a command-line `-fvisibility` flag. But it's still unclear to me what effect someone would expect `-fvisibility=hidden` to have when compiling OpenCL code. What are these symbols being hidden-by-default *from*, if not the host-side OpenCL runtime? Is there ever actually have a device-side dynamic linker? https://reviews.llvm.org/D53153 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
