On Tue, 2019-06-25 at 15:57 -0700, Nick Desaulniers wrote: > consider most other GNU C extensions. How do I > test whether they exist in my compiler or not? Is it everything or > nothing (do they all have to exist?).
Until such time as the linux source code supports alternate mechanisms for existing gcc extension uses, I think yes. > In those cases you either end > up shelling out to something like autoconf (which is what I consider > the current infra around CONFIG_CC_HAS_ASM_GOTO), or code filled with > tons of version checks for specific compilers which are brittle. Or just one... > Of the two cases, now consider what happens when my compiler that > previously did not support a particular feature now does. In the > first case, the guards were compiler agnostic, and I *don't have to > change the source* to make use of the feature in the new compiler. In > the second case, I *need to modify the source* to update the version > checks to be correct. [] > Back to your point about adding a minimal version of Clang to the > kernel; I don't really want to do this. For non-x86 architectures, > people are happily compiling their kernels with versions of clang as > old as clang-4. Perhaps: #if defined(CONFIG_X86_32) || defined(CONFIG_X86_64) #define CLANG_MINIMUM_VERSION 90000 #elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) #define CLANG_MINIMUM_VERSION 40000 #else etc... #endif #if CLANG_VERSION < CLANG_MINIMUM_VERSION etc... #endif > and if it continues to work for them; I'm happy. And > if it doesn't, and they raise an alarm, we're happy to take a look. > Old LTS distros may have ancient builds of clang, so maybe some kind > of hint would be nice, but I'd also like to support older versions > where we can and I think choosing clang-9 for x86's sake is too > x86-centric. A version check on CONFIG_JUMP_LABEL is maybe more > appropriate, so it cannot be selected if you're using clang && your > version of clang is not clang-9 or greater? The now non-portable nature of .config files might be improved.