[PATCH] D107304: [clangd][query-driver] Extract GCC version from the driver output

Sam McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 4 11:31:03 PDT 2021


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



More information about the cfe-commits mailing list