kadircet added a comment. In D107304#2922806 <https://reviews.llvm.org/D107304#2922806>, @ArcsinX wrote:
> @kadircet Thanks for clarification. Now your position is clear for me. > > But clang was designed as a drop-in replacement for GCC: > > - https://clang.llvm.org/docs/LanguageExtensions.html#introduction > - https://clang.llvm.org/features.html#gcccompat > > I do not have any proves that clang is 100% compatible with any GCC version, > but also I can't find any evidence that the most compatible version of GCC is > 4.2.1 The existence of query-driver mechanism is proof that clang is not 100% GCC compatible (anymore). Instead of going with the query-driver approach we wanted to update custom toolchain support to mimic the GCC behaviour, but we gave up because it would get out-of-date again. > I really faced the problem with that default 4.2.1 on a project: strange > errors in clangd and it was really hard to understand that the reason was > `__GNUC__ == 4`. `-fgnuc-version=<real GCC version here>` addition helped me > to solve this. That's why I think that it can be added automatically (and > `.clangd` can be used to override this with `4.2.1` (or any other) if user > doesn't want this automatic GCC version detection =) ) I definitely get your point too. But I am not convinced that changing the default behaviour here is going to be beneficial for majority of the users. In other words, if we keep things as-is today, people that want a specific GNUC version can set clangd to parse their code with that specific version they know about and face the consequences if clang doesn't provide the same extensions GCC does. Or we can change the behaviour to what you propose and make people that has a broken parse to change their GNUC version to something they have no idea about (they won't know that they should set it to 4.2.1 or any other specific version). 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
