linux

> 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 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 s

`asm goto` was the big one. The x86_64 maintainers broke the clang builds very intentionally just after we had gotten x86_64 building (with necessary patches upstreamed) by requiring compiler support for that GNU C extension. This was right around the time of meltdown+spectre, and the x86_64 maintainers didn't want to support fallbacks for older versions of GCC (and ToT Clang at the time) that lacked `asm goto` support for the initial fixes shipped under duress (embargo). `asm goto` requires plumbing throughout the compiler, and I've learned more about register allocation than I particularly care... Fixing some UB in the kernel sources, lots of plumbing to the build system (particularly making it more hermetic). Getting the rest of the LLVM binutils substitutes to work in place of GNU binutils was also challenging. Rewriting a fair amoun