rjmccall wrote: I think Eli is suggesting something like the rule for [@available](https://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available): - If a builtin is unconditionally available, you can always use it without any diagnostics. - If a builtin is only available on specific subtargets, you can only use it in a block that's guarded by an `if (some_intrinsic(...))` condition that will only pass if you're running on one of those subtargets.
So it's not that adding a check for the builtin will suddenly cause un-checked calls to it to fail, it's that you have to have such a check to use it in the first place, which makes sense because it's not always available on the target. Note that the `@available` model also includes an attribute for marking your own functions as conditionally available, in which case (1) the entire body of the function is considered guarded but (2) you have to guard calls to it. That might be a necessary enhancement for your feature, too. https://github.com/llvm/llvm-project/pull/134016 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
