gcc, for the sake of wanting to make it hard to call it from proprietary front-ends, is architecturally tangled. (See http://comments.gmane.org/gmane.comp.gcc.d

gcc, for the sake of wanting to make it hard to call it from proprietary front-ends, is architecturally tangled. (See http://comments.gmane.org/gmane.comp.gcc.devel/59296 http://comments.gmane.org/gmane.comp.gcc.devel/59296 - the "new methods" mentioned there never emerged). Proposals to refactor it have been vetoed by rms. As a result, gcc is substantially harder to understand and work on than other compilers of similar scope. As a result, new development effort, both personal and corporate, is going into clang. As a result, even if clang is only approximately at parity with gcc now, people expect it to improve faster in future, and therefore to be a better choice now. All of these contribute to what http://lists.freebsd.org/pipermail/freebsd-questions/2012-June/242709.html http://lists.freebsd.org/pipermail/freebsd-questions/2012-Ju... says are non-licence reasons to replace gcc: 1) GCC's continuously increasing propensity to generate "bad code", 2) The inability of GCC mamintainers to fix _long-standing_ bugs, some have been identified for over a decade, and have not been fixed. 3) The continuously increasing trend of introducing 'non standard' features, 4) The growing need to 'write around' correct/valid code that GCC will not compile. 5) The fact that the GCC code is 'unmaintainable' -- *NO*ONE* (other than someone who has been working with GCC internals for "forever" --a decade at an absolute minimum) has any chance of 'understanding' what it is doing internally.