In the context of #19816, we found that

[...] clang will also populate __GNUC__, and while the default value is not documented (from what I saw), it just so happens to be 4, see:

• https://github.com/llvm/llvm-project/blob/llvmorg-18.1.3/clang/lib/Driver/ToolChains/Clang.cpp#L6892
• https://github.com/llvm/llvm-project/blob/llvmorg-18.1.3/clang/lib/Frontend/CompilerInvocation.cpp#L3838
• https://github.com/llvm/llvm-project/blob/llvmorg-18.1.3/clang/lib/Frontend/InitPreprocessor.cpp#L794

In other words, the 4 here is load-bearing for clang support, and we cannot increment it to our lowest supported GCC version, for example. We definitely need to document this.

While looking at bumping the GCC minimum version (#20478), I ended up stumbling over at least one place where we require GCC >=4.4 through macros, which will disable the respective feature on clang (which defaults to GCC 4.1).

There's also many places where __GNUC__ occurs in the boost submodule, though I haven't audited them all for correctness (and many of them do correctly add || defined(__clang__) or || __clang_major__ >= <some_major_ver>).

I propose that we add explicit guards like boost does (and simplify our logic to avoid __GNUC_MINOR__, since our minimum supported version is far beyond 4.x anyway). Other places that only check whether __GNUC__ is defined should be OK, as clang will set it by default, though we could be more explicit there as well.

Finally, a separate mention for places that intentionally avoid clang. I'm quite sure that in these cases, similar functionality exists on clang as well, and we should enable the same optimizations there as well: