4 ms·

> I spent a good part of my career (nearly a decade) at Google working on getting Clang to build the linux kernel Did this come down to making Clang 100% gcc c

> I spent a good part of my career (nearly a decade) at Google working on getting Clang to build the linux kernel Did this come down to making Clang 100% gcc compatible (extensions, UDB, bugs and all), or were there any issues that might be considered as specific to the linux kernel? Did you end up building a gcc compatability test suite as a part of this? Did the gcc project themselves have a regression/test suite that you were able to use as a starting point?

ndesaulniers 9mo ago
> extensions Some were necessary (asm goto), some were not (nested functions, flexible array members not at the end of structs). > UDB, bugs and all Luckily, the kernel didn't intentionally rely on GCC specifics this way. Where it did unintentionally, we fixed the kernel sources properly with detailed commit messages explaining why. > or were there any issues that might be considered as specific to the linux kernel? Yes, https://github.com/ClangBuiltLinux/linux/issues https://github.com/ClangBuiltLinux/linux/issues is our issue tracker. We use tags extensively to mark if we triage the issue to be kernel-side vs toolchain-side. > Did you end up building a gcc compatability test suite as a part of this? No, but some tricky cases LLVM got wrong were distilled from kernel sources using either: - creduce - cvise (my favorite) - bugpoint - llvm-reduce and then added to LLVM's existing test suite. Many such tests were also simply manually written. > Did the gcc project themselves have a regression/test suite that you were able to use as a starting point? GCC and binutils have their own test suites. Folks in the LLVM community have worked on being able to test clang against GCC's test suite. I personally have never run GCC's test suite or looked at its sources.

4 ms·

> I spent a good part of my career (nearly a decade) at Google working on getting Clang to build the linux kernel Did this come down to making Clang 100% gcc c

by HarHarVeryFunny 9mo ago

ndesaulniers 9mo ago
> extensions Some were necessary (asm goto), some were not (nested functions, flexible array members not at the end of structs). > UDB, bugs and all Luckily, the kernel didn't intentionally rely on GCC specifics this way. Where it did unintentionally, we fixed the kernel sources properly with detailed commit messages explaining why. > or were there any issues that might be considered as specific to the linux kernel? Yes, https://github.com/ClangBuiltLinux/linux/issues https://github.com/ClangBuiltLinux/linux/issues is our issue tracker. We use tags extensively to mark if we triage the issue to be kernel-side vs toolchain-side. > Did you end up building a gcc compatability test suite as a part of this? No, but some tricky cases LLVM got wrong were distilled from kernel sources using either: - creduce - cvise (my favorite) - bugpoint - llvm-reduce and then added to LLVM's existing test suite. Many such tests were also simply manually written. > Did the gcc project themselves have a regression/test suite that you were able to use as a starting point? GCC and binutils have their own test suites. Folks in the LLVM community have worked on being able to test clang against GCC's test suite. I personally have never run GCC's test suite or looked at its sources.