>you should be able to compile git linux git with gcc 4.7.4 (the last C gcc which has beyond than enough extensions to write a kernel)
By this logic why not write the entire kernel in assembly? Tools evolve and improve over time and it makes sense to migrate to better tools over time. We shouldn't have to live in the past because you refuse to update your compiler.
That's obviously not their logic at all. Trying to diminish this to "OP refuses to update compiler" is frankly disrespectful of them & their actual point.
To me their logic is that their old tool works just fine so they shouldn't have to upgrade it. He essentially said that having a plan to upgrade to a newer version of the language or to a more up to date toolchain is planned obsolescence. He seems to want to be able to use his specific version of his compiler to the end of time. To me I don't quite get the justifications of this perspective as GCC is free software and it is simple to upgrade.
Thank you, that's a great reply to his comment. My first impression of his comment was that the kernel project shouldn't chase the latest-and-best compiler releases -- or similarly the most recent C language changes; rather, a boring-technology approach is sensible for such a foundational project as Linux. I see your point, though, that GCC is simple to upgrade. (If I were making the tech decision here, I'd want to ensure that newer GCC's didn't introduce features that I thought were too risky for my project, or at least that I could disable/restrict those features with flags.)
It's not completely arbitrary. Notice that they said "the last C GCC". After that version, GCC started using C++ in the compiler itself. I can see why some people would see that as a complexity line that must not be crossed, as it makes bootstrapping harder.
