Kernel compiler

Not only can, but most likely will; the main issue with function annotations right now is that we still have rather messy type system implementation on the sparse side. It *is* getting better and that kind of stuff (function classes, annotations, work with call graph, etc.) is very much a part of goals. Secondary problem is that we'll need a bit more work on linearizer, but it's less painful.

However, that's not related to having sparse in the kernel tree (to be honest, I do not think it's a serious issue either way - sparse lives in another repo on kernel.org, after all; OK, 3 repos, but that's a separate
story).

What's much more important, and completely missed in all that discussion is that sparse uses for analysis, typechecking, etc. and sparse use as filter that would feed gcc are very, very different animals. Once you've got to parser, you lose the ability to do pretty-print-to-C. And most of the useful things can't be done without parsing. Use of modified preprocessor to extend C is a way to really lousy language; the interesting stuff lives at phase 7 and after it.

So it's either "forget about gcc, have generating *.s by sparse mandatory", which requires backend for all targets or it's "sparse used for extra analysis, in addition to some C compiler and with input files for sparse being acceptable for the latter".

_That_ is the hole in Ingo's "we could use sparse to replace gcc" handwaving. And AFAICS it's not pluggable. I wouldn't mind seeing other compilers and I certainly expect more sparse _annotations_ in the kernel, but sparse-as-kernel-compiler-instead-of-gcc really, honestly will require full set of backends for all kernel targets. Plus a lot of work on data flow analysis, etc.