karolherbst wrote: > > Maybe there is a better tripple to be used in this case? However we do want > > to compile to SPIR-V (with the native target in the future anyway), it's > > just it enables a bunch of things automatically. > > I'm not sure I understand what the issue is. The defines here just declare > that the extension is available, it does not enable them. You need to use the > pragma to actually enable the extension (which the header does to enable > required types later on in that file for declarations, but it cleans up after > itself with `#pragma OPENCL EXTENSION all : disable` at the end > > clang already does have -cl-ext for enabling / disabling extensions on the > command line, I'm not sure if we have an equivalent for changing the target's > reported set
ah yeah, that's what I meant. Like if you are a normal CLI user and compile to SPIR-V I think it's reasonable to do it like that, just for users like mesa who actually implement an OpenCL runtime, we have to be very selective about what to advertise to conform to the OpenCL and OpenCL C spec as the official conformance test suite checks if API queries match what defines are enabled at compile time at runtime. So far simply adding `__SPIR__` and `__SPIRV__` to the undefs solves this problem for us. But if there are others doing similar things, they might want to know about this, though most might just compile to a hardware target and never run into this issue in the first place. https://github.com/llvm/llvm-project/pull/126908 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
