jhuber6 wrote: > Marking as requesting changes so we don't accidentally land, because I've got > questions about whether we want to go down this route. > > 1. GCC has `__has_builtin`, so how do they handle offloading targets? Do > they have the same odd behavior where `__has_builtin` returns true for > builtins it cannot actually emit code for? > > 2. Given that `__has_target_builtin` seems to have the semantics everyone > would expect from `__has_builtin`, do we want to consider deprecating > `__has_builtin` so that downstreams have time to adjust but we eventually end > up with a less confusing builtin? > > > It really seems to me that `__has_builtin` has a broken design because of > compilations where we try to hide a two-pass compilation as though it were > one-pass and it seems like we're going to confuse folks with that behavior. > If I could wave a magic wand, I would say `__has_builtin` should behave > exactly how `__has_target_builtin` is behaving in this PR and that a reliance > on `__has_builtin` behaving how it does today is relying on a bug.
That's what the initial proposal / patch was, but that got reverted because it broke some CUDA on Arm sources. https://github.com/llvm/llvm-project/pull/126324 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
