mstorsjo added a comment. In D67414#1668443 <https://reviews.llvm.org/D67414#1668443>, @rsmith wrote:
> 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++? I think it's a rather uncommon combination (I think most use of gnu_inline is together with extern), so I wouldn't think that there's a lot of users relying on the current behaviour (in clang-only codebases), but I have no data to back it up with. > 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. It did come up in mingw-w64 recently; new header additions (that were developed with gcc) broke when built with clang (due to multiple definitions of a symbol). It's been rectified for now by avoiding this combination (for compatibility with existing clang versions) though. 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
