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

Reply via email to