rsmith added a comment.
Seems very surprising to me that the `gnu_inline` attribute has different
behavior in their C and C++ frontends. That said, it looks like it's a behavior
that they document; their documentation says "In C++, this attribute does not
depend on extern in any way, but it still requires the inline keyword to enable
its special behavior." and that matches their observed behavior. And they
behave this way even for functions in `extern "C"` blocks. The question for us,
then, is do we want to be compatible with C source code built as C++ (that is,
the status quo) and C++ source code using this attribute and targeting older
versions of Clang, or with g++?
Is Clang's current behavior actually causing problems for some real use case?
Changing this behavior is not without risk, and the old behavior is certainly
defensible.
If we want to match GCC's behavior for `gnu_inline` in C++ mode, we should
think about whether we also want to permit things like:
__attribute__((__gnu_inline__)) extern inline int externinlinefunc() { return
0; }
int externinlinefunc() { return 1; }
(with or without the `extern`), which g++ allows and clang rejects.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D67414/new/
https://reviews.llvm.org/D67414
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
