================
@@ -1818,8 +1819,21 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok) {
// usual allocation and deallocation functions. Required by libc++
return 201802;
default:
+ // We may get here because of aux builtins which may not be
+ // supported on the default target, for example if we have an X86
+ // specific builtin and the current target is SPIR-V. Sometimes we
+ // rely on __has_builtin returning true when passed a builtin that
+ // is not supported on the default target due to LangOpts but is
+ // supported on the aux target. See
+ // test/Headers/__cpuidex_conflict.c for an example. If the builtin
+ // is an aux builtin and it can never be supported on the default
+ // target, __has_builtin should return false.
+ if (getBuiltinInfo().isAuxBuiltinID(BuiltinID) &&
+
getBuiltinInfo().isAuxBuiltinIDAlwaysUnsupportedOnDefaultTarget(
----------------
AaronBallman wrote:
It may be that gating it on something other than the triple is undesirable; I'm
not certain. The point is more that builtin authors specify what language modes
the builtin should be exposed in and exposing the builtins in other modes than
that is really hard to reason about.
https://github.com/llvm/llvm-project/pull/121839
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
