On Tue, 14 Sep 2010, Diego Novillo wrote: > On Tue, Sep 14, 2010 at 06:09, Richard Guenther > <richard.guent...@gmail.com> wrote: > > On Tue, Sep 14, 2010 at 12:33 AM, Ian Lance Taylor <i...@google.com> wrote: > >> Manuel López-Ibáñez <lopeziba...@gmail.com> writes: > >> > >>> In the same sense that adding clang->gcc means that there is less > >>> motivation for developers to improve the current C/C++ FEs. > >> > >> From the perspective of gcc, I think the goal of clang->gcc would be to > >> replace the current frontends entirely. > > > > Yes, doing clang->gcc would get us the C family frontends disentanglement > > from the middle-end "for free". > > Indeed. I would be interested to know what our C/C++ maintainers > think of this possibility. Jason, Mark, Joseph?
I think it's crazy on multiple grounds. * Most obviously for users, backwards compatibility. Replacing large user-visible pieces in mature code with an established user base is hopeless for compatibility. (I make no claims about the user base for GNU ObjC.) We should be working strictly with incremental development, avoiding regressions, improving compatibility with previous GCC releases where indicated by user feedback, not making massive changes that are bound to be incompatible - we haven't been careful enough about compatibility in the past. Maybe people working in middle-end pieces without much of a user-visible interface don't notice this. (Back ends do end up with quite a large interface - subtargets, options, pragmas, attributes, built-in functions, ... - that also makes them hard to replace safely, but that interface is far smaller than the front-end interface.) * Diversity in software (and hardware) implementations is intrinsically a good thing. I consider that one of the greatest problems in computer security today is an insufficiently diverse ecosystem; it would be much better if no front end, back end, programming language, operating system, hardware architecture, ... had more than maybe a 10% market share. It's also valuable for more than security if there are many implementations available to try and choose from for a particular purpose. Enabling combinations of front ends, optimizers, back ends from different places improves diversity; throwing out options reduces it. * The battle for software freedom and against closed computational devices and components for such devices must be fought on many fronts. I think a critical part of this is maintaining and improving the commons of copyleft, preferably GPLv3, software that is freely available for those who will preserve user freedom. When there is a choice of copyleft and non-copyleft free software in a particular area and the non-copyleft software is better in some way, the reaction should not be to replace the copyleft software, but to improve it, learning from the competition, and enhance the copyleft commons to encourage people to choose freedom and the greater amount of software available if they do so. And I very definitely consider the contribution to software freedom to be an important part of contributing to widely used copyleft software, and copyleft software generally to be a greater contribution to society, and so intrinsically more desirable to work on, than non-copyleft. -- Joseph S. Myers jos...@codesourcery.com
