Four months ago a debate on the lkml suggested that support for GCC 2.95 would be around for a long time [story], but a more recent thread suggests otherwise. 2.6 maintainer Andrew Morton put together a small patch to remove support for 2.95, and discussion continued to explore which versions of GCC 3.x should be supported. Andrew explained:

"2.95.x is basically buggered at present. There's one scsi driver which doesn't compile due to weird __VA_ARGS__ tricks and the rather useful scsi/sd.c is currently getting an ICE. None of the new SAS code compiles, due to extensive use of anonymous unions. The V4L guys are very good at exploiting the gcc-2.95.x macro expansion bug (_why_ does each driver need to implement its own debug macros?) and various people keep on sneaking in anonymous unions.

"It's time to give up on it and just drink more coffee or play more tetris or something, I'm afraid."

The question was recently raised on the lkml why such a wide range of GCC [forum] versions were being actively supported by the Linux kernel. One reason offered was, "because the new compilers are a lot slower", an argument that left some perplexed. "Why is this an issue when compiling a kernel? How often do you compile your kernel?"

Linux creator Linus Torvalds agreed that the speed of the compiler was indeed one of the reasons that older versions are still supported, "for some people that is literally where _most_ of the CPU cycles go". Beyond that, he pointed out that earlier versions of the GCC 3.x compiler would generate worse code than 2.95.x, and that they were simply buggier. Linus explained, "for a _long_ time, the only reason to upgrade gcc was literally C++ support: basic C support was getting _worse_ with new compilers in pretty much every regard." He went on to add, "things seem to have improved a bit lately. The gcc-3.x series was basically not worth it for plain C until 3.3 or so."