wenju-he wrote: > I'd expect the libclc build (or any other runtime support library) to > consistently use the same language version independent of the target. If the > target doesn't support that version (which IIRC isn't actually a hard error > anywhere) and fails to compile on some feature, those should be carved out > into separate version dependent build (as in, this isn't a compile target > property but a specific build target property)
LGTM. That means we compile for the last OpenCL version, which is 3.0, and enable all OpenCL extensions/features, right? libclc is implemented using functions supported by clang, so it is unlikely a target has libclc build error in generic libclc files that are shared for all targets. When libclc is linked to application module, libclc built-ins implementation of unsupported extensions/features won't be linked in because these built-ins won't exist in the user module. If the application code uses an unsupported extension, frontend would report error already. There could be problem if application modules links in a supported libclc built-in function which calls another libclc built-in that belongs to unsupported special extension/feature, but I think this scenario is unlikely. @frasercrmck What do you think? https://github.com/llvm/llvm-project/pull/135733 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
