> So is GCC adding a toolchain similar to the one LLVM has around its bitcode?
Not as far as I can tell.
> In this instance, a way to write a text representation of an internal data structure that represents code, run a single optimization pass over that data structure, dump the result, compare the result with serialized text representation of "expected value"?
That's already existed for ages. See the -fdump-tree-* family of functions. It also doesn't do anything llvm-like.
So all that hasn't existed for ages. Only dumping the intermediate representation has existed for ages, but not loading it and not running the middle-end of the compiler on the loaded IR.
Right, the historical problem with loading GIMPLE was that it still required all sorts of frontend specific bits.
Also, tons of things reused tons of bits for different purposes :)
Way the heck back when (pre-c++), i started splitting up just the decl hierarchy in trees to try to get things to stop reusing bits, and to expose what would be required to make it independent of the frontendy bits.
Not as far as I can tell.
> In this instance, a way to write a text representation of an internal data structure that represents code, run a single optimization pass over that data structure, dump the result, compare the result with serialized text representation of "expected value"?
That's already existed for ages. See the -fdump-tree-* family of functions. It also doesn't do anything llvm-like.