rsmith added a comment. In https://reviews.llvm.org/D53153#1263771, @scott.linder wrote:
> The rationale is that `-fvisibility` only affects the default, and already > does not apply in many cases. For example, see the rest of the conditions > above the fvisibility check in `getLVForNamespaceScopeDecl`: when > `Var->getStorageClass() == SC_Static` the linkage is (usually) internal and > the visibility is default. Visibility is meaningless for an internal-linkage declaration. > I think one question is whether OpenCL language semantics allow us to make > these visibility determinations; I am going off of the APIs available to > access symbols. `-fvisibility` is not governed by the OpenCL specification; it's a Clang / GCC extension, and we get to determine its semantics, which generally override the rules from the language model we're implementing. I'm a little surprised that symbol visibility is even meaningful when compiling GPU code. Can you give some more background on that? To the extent that visibility is meaningful, it does seem to make sense for `kernel` to imply default visibility in the same way an attribute would, since it's an unambiguous marker that the function is intended to be called from outside the DSO. It's less obvious to me that the same is true for global variables; is there no distinction in OpenCL between global variables that can be accessed by the host and global variables that are internal to the device-side computation? https://reviews.llvm.org/D53153 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
