efriedma added a comment. In D148723#4283094 <https://reviews.llvm.org/D148723#4283094>, @serge-sans-paille wrote:
> In D148723#4280916 <https://reviews.llvm.org/D148723#4280916>, @efriedma > wrote: > >> The point of an "inline builtin" is that the inline function is actually the >> original function; it's just the inline implementation is only used in >> limited circumstances (in particular, it can't be used recursively). >> Changing the linkage could have unexpected side-effects. > > That's not my understanding. An inline builtin provides an alternate > implementation of the builtin that usually wraps the original builtin in some > way. It's not meant to be externally visible (it would probably collide with > libc's implementation in that case). The "linkage" here is the linkage of the declaration. Any code that refers to the declaration has to treat it like something externally visible. Off the top of my head, not sure how much it matters for C, but the linkage at the AST level has cascading effects in C++. For normal C99 inline functions, there's a definition somewhere else, but there's an inline body which is supposed to be equivalent. Sort of a substitute for "linkonce", which doesn't normally exist in C. The issue with builtins specifically is that glibc headers do weird things, and the inline version ends up recursively calling itself. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D148723/new/ https://reviews.llvm.org/D148723 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
