sammccall added a comment. I disagree that this is a pointless discussion, FWIW.
The `__GNUC__` macro is used for compiler feature (or bug?) detection. Clang's current answer is "yes we are GCC >=4, but no we are not GCC >=5". This causes the codebase to reject the compiler, because it relies on features/absence of bugs from GCC 5. @ArcSinX any idea what these are, concretely? If clang has those features/lacks those bugs, there's some value in making it pass the feature check. Problem is, there are significant extensions in GCC 4.3 that clang doesn't implement. Per user's manual <https://clang.llvm.org/docs/UsersManual.html>: > clang does not support `__builtin_va_arg_pack`/`__builtin_va_arg_pack_len`. > This is used rarely, but in some potentially interesting places, like the > glibc headers, so it may be implemented pending user demand. Note that > because clang pretends to be like GCC 4.2, and this extension was introduced > in 4.3, the glibc headers will not try to use this extension with clang at > the moment. See also this thread <https://lists.llvm.org/pipermail/cfe-dev/2012-May/021495.html> and D51011 <https://reviews.llvm.org/D51011>. So we can't simply bump clang's compatibilty claims. --- For clangd, I think this illustrates why implicitly increasing `__GNUC__` (e.g. via query-driver) isn't safe in general. For files that **optionally** use e.g. `__builtin_va_arg_pack` (like glibc headers), we'll direct the preprocessor to take that path and then reject the code. With codebases that refuse to build at all without large `__GNUC__` but actually mostly parse fine, this is unfortunate, but the sort of thing that users probably should opt into. The symptom `#error You need GCC X.Y to build this code` is much easier to understand than the results of trying to use unsupported extensions. I think the best we can do here is document the workaround. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D107304/new/ https://reviews.llvm.org/D107304 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
