28 ms·
This is a great step forward. Compiling with clang will allow kernel developers to run code checks and analysis unavailable to gcc. This will definitely have a
by bitcharmer 9y ago
This is a great step forward. Compiling with clang will allow kernel developers to run code checks and analysis unavailable to gcc.
This will definitely have a positive effect on code quality.
Not even mentioning it should be a little bit easier to configure IDEs like CLion for working with Linux source tree.
- taeric 9y agoIs there a list of checks and analysis that you can't do from a gcc pipeline?
- kevindqc 9y agoMaybe he's talking about the sanitizers? eg: https://clang.llvm.org/docs/AddressSanitizer.html https://clang.llvm.org/docs/AddressSanitizer.html
- pksadiq 9y agoThose sanitizers are present in gcc too[0]. [0] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.h...
- kevindqc 9y agoah! thanks
- ndesaulniers 9y agoPresent != Equal, feature wise. Not by a long shot. At the same conf, one of my friends who develops the sanitizers said it's easier to develop for LLVM, so that's where Dev work is done.
- pksadiq 9y ago> Present != Equal, feature wise. It is developed by google[0] afaik. The link says it is present in LLVM and gcc. I don't know what makes the difference (may be License?). On the contrary I have felt gcc better for my work. I have been following a clang bug[1] for long and have seen no fix so far. [0] https://github.com/google/sanitizers/wiki/AddressSanitizer https://github.com/google/sanitizers/wiki/AddressSanitizer [1] https://bugs.llvm.org/show_bug.cgi?id=23910 https://bugs.llvm.org/show_bug.cgi?id=23910
- pebers 9y agoClang has better support for plugins and calling it as a library; that sort of thing was resisted by GCC. Google has a bunch of large-scale tooling based on the Clang frontend which AFAIK wouldn't be possible with GCC.
- jcelerier 9y agosure sure, but today (and even two years ago) you can add -fsanitize={address,undefined,etc} on both clang and gcc. So this does not answer the question.
- deleted 9y ago[deleted]
- sanxiyn 9y agoAll sanitizers are also available in GCC, so no.
- bitcharmer 9y agoAre you sure? Last time I checked the ones llvm had and gcc did not were: Dynamic alloca overflow detection Symbol size changing for global variables Adaptive global redzone sizes Invalid pointer pairs detection Support for no_sanitize attribute Support for dead stripping of globals on Linux I might be out of date on some or even all, so please correct me where I'm wrong. Thank you in advance.
- ndesaulniers 9y agoWrong. Not all kernel versions.
- albinofrenchy 9y agoSanitizers are run-time tools; I'd be surprised if any of them worked out of the box with the kernel. Address sanitizer was "ported" to the kernel a while ago; not sure if UBSAN is or will be in the future.
- ndesaulniers 9y agoThere are kernel versions. KASAN, KUBSAN, KMSAN.
- melkiaur 9y agothe static analyzer, along with all the other checks available from clang-tidy: https://clang.llvm.org/extra/clang-tidy/checks/list.html https://clang.llvm.org/extra/clang-tidy/checks/list.html
- taeric 9y agoI'm surprised there is a static analyzer available for clang that isn't somewhat equivalently offered in gcc toolchains. I guess I'm assuming folks would be using something like Coverity for major static analysis. Specifically, this sounds like it is just preferring the other toolchain. Are there literally things that don't have equivalents?