For someone not following the project, what's the reason for deprecation and switch over to LLVM ?
LLVM is designed to be modularized and embedded in other binaries and toolchains, which makes it easier to build extensions and tooling around it.
In addition to having a mountain of legacy code, gcc's project steering is philosophically opposed to allowing non-free (as in GPL) plugins [https://lwn.net/Articles/582242/]. Because of this, developers looking for the most flexible toolchain seem to be backing slowly toward the exist regarding gcc, as the Clang / LLVM steering team has made clear that they don't see similar incompatibilities between their tool and the way developers choose to use it.
There is a project going on to break the gcc down into components [https://gcc.gnu.org/wiki/rearch], so time will tell what comes of these two toolchains.
I think that's the right philosophy. Why shouldn't you be contributing your plugin if you derive value from it, so that other people can derive value from it just as you did with GCC (if you distribute it that is - if you wrote it inhouse for internal use, then it doesn't matter at all!).
It's not like the code generated by GCC is licensed virally.
It's a shame that GCC's code is hard to modify, and difficult to extend. LLVM's permissive license means that contributions don't flow back unless it's favourable to the entity contributing it (such as good PR). I imagine that if somebody/some company wrote an excellent, non-obvious, non-trivial toolchain using LLVM, derive profit from it, they will not _want_ to contribute it back.
So, the FSF sacrificed technical needs in order to serve philosophical goals.
There are multiple reasons to push code up the chain to the wider world beyond fuzzy feelings regarding your corporation.
Never underestimate the benefits of outsourcing your code maintenance and integration costs. ;)
Richard Stallman reasoned that by exposing an interface to other applications, or allowing other applications to access or modify intermediate code/trees, closed source proprietary applications could be built around GCC.
He was probably right ... but we all ended up with a worse compiler.
Last time I checked gcc binaries beat Clang performance wise.
Several extension mechanisms have been built out in the last few years, including plugins for intermediate passes of compilation, and a library to operate as a JIT.
Eddyit: Spelshing.
B) If you ever want to make a change to the toolchain, HARD SWERVE on supporting GCC. It's a liability if you need to modify it at all. This may have more to do with what Google wants to support rather than any effect on the end user.