GCC already "shriveled up and died" once -- the egcs project got so far ahead of regular GCC in development that the FSF basically just said, "congratulations, you are the new maintainers and your project is now the official GCC mainline".
GCC is stagnant, but the dynamic pace of development on the Clang front means that either the GCC developers will adapt, or the community will adapt GCC for them.
This is actually not what happened with EGCS at all. EGCS was a political fight.
The FSF in fact, fought EGCS all the way until it was completely clear that GCC would die.
Could you provide a source? I'd like to learn more about this. (The politics of open-source software is interesting because the underlying motivations are probably still around and motivating other people).
The reunification is kind of glossed over here, but what happened was the FSF fought it all the way, realized EGCS would win, and accepted it back.
GCC got concessions as part of this reunification. The concessions were that GCC would have it's own steering committee, and that we could appeal any RMS decision to the board of the FSF.
For one, there wasn't any viable competition at the time. Your options were GCC, or a commercial compiler. If you actually needed access to the source code of the compiler for any reason, GCC was your only option.
So, when it became clear that the FSF and the community wanted to take GCC in different directions, the obvious choice was to fork GCC. The fork developed far more rapidly than the original, draining developer time (and users, for that matter) from GCC mainline. Basically, at the point where the FSF anointed egcs as the new GCC, the original GCC project was already dead.
Things are a bit different nowadays.
There are already disagreements between what people wanted to do with GCC, and the FSF. Especially around the tool support the article talked about - the FSF are against reorganizing GCC so that parts can be used as a library for political reasons. They were against plugins for the same reason originally. They have been resisting any attempts to clean up or modernize the codebase (they've been doing it, but very slowly, because it takes the steering committee a long time to... erm... steer).
There's an alternative - Clang / LLVM, which is built around that kind of tool support, has less niche stuff to get in the way, cleaner, simpler codebase, no legacy stuff. A good few GCC developers have jumped behind that instead, rather than trying to work against the FSF, and Clang isn't having the kind of problems attracting new developers that GCC is.
At this point, it does look like GCC is in trouble. The problem is that there might not be anything that anyone can do about it. As with all large projects with a long history, GCC has a hell of a lot of inertia, and it would take massive effort to shift the direction of the whole project, and make the changes that need to be made, especially considering that they can't just stop and spend a couple of years refactoring (which would definitely kill GCC).
Actually the reasons against plugins and GCC being used as 'a library' went beyond mere politics, it was also a practical consideration as it affected the relevance/existance of GCC.
Back then the there was an obvious threat of GCC becoming little more than a backend/frontend solution for proprietary interests which could lead to the open source part eventually wither and die.
Steve Jobs when at NeXT illustrates this problem as he tried to combine NeXT's proprietary ObjC frontend with GCC's backend and sell it under the reasoning that the 'end user would do the linking', he couldn't legally do so which is how GCC ended up with ObjC support which it otherwise hadn't, atleast not then.
Nowadays open source is established and it's benefits are well proven so these choices may look overly paranoid when viewed in the open source landscape of today, but back then and for a long time in GCC's development they certainly weren't.
The fact that an open source free compiler toolchain like GCC has established itself as such a 'de facto' solution has obviously had an incredible impact on the acceptance of open source in general, not to mention that Linux, the open source BSD's, and tons of other open source projects (and likely lots of proprietary projects aswell) would never have gotten anywhere near where they are today had it not been for the existance of GCC, a top-notch compiler toolchain free of charge and free to distribute.
One of the concerns mentioned is "GCC needing to bring in newcomers by young students and experiments from academia, while most new developments these days are using LLVM", i.e. that there _eventually_ will not be sufficient community to make those adjustments. I think that concern is justified and may not even be limited to gcc. Any open source project without significant commercial backing will have problems staying attractive to developers for decades. Why would anybody volunteer to work on a decades old and, because of it, somewhat crusty, codebase for free?
Yes, gcc has commercial backers, too, but I think at the moment most of them are more willing to pay for the support of additional architectures or architecture variants than for new language features (at the moment; that can change if C++11 gets more commonly used)
It's theoretically possible to copy the code from Clang to GCC, but the FSF wants the copyright, so it doesn't seams to be very probable. Another problem is that the license of GCC is more restrictive, so I think that most of the people would continue to work in the Clang.
It's possible to fork the code, but it's more difficult to fork the community. It's the problem that the BDFL have to solve to survive.
GCC is stagnant, but the dynamic pace of development on the Clang front means that either the GCC developers will adapt, or the community will adapt GCC for them.