On Wed, 2013-01-23 at 19:59 +0000, Alec Teal wrote: > On 23/01/13 19:38, Diego Novillo wrote: > > [ We have drifted way off the original subject. ] > > > > > > On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker <u...@cse.iitb.ac.in> wrote: > > > >> Yes, absolutely. And GCC community should consider it important to bring in > >> newcomers particularly young students and experimenters from the academia. > >> > >> Why is it that most student projects these days are on LLVM and not on GCC? > >> Had these students been doing projects on GCC, some of them may turn > >> contributors in future. > > Yes. This is an issue for the long term viability of GCC as a > > project. In fact, I sometimes think that we may be past the tipping > > point. > > > > Note that the very set of developers that can fix these problems are, > > traditionally, the least likely to do much about it. These developers > > are already comfortable with the codebase, they know how to do the > > things they are hired to do and employers are largely on the same > > boat. Additionally, established developers will generally resist > > change, because these changes lead to short-term instability and bugs > > (the releng/maintainer mindset). > > > > Evolving this codebase is largely a thankless and difficult job. It's > > technically interesting to me, but I know I can only do so much. We > > have other demands on our time and often this conflicts with the > > nature of these changes. Some developers have done some work here and > > there to improve the codebase, but GCC's accumulated technical debt is > > large. > > > > If this trend continues, the pool of experienced GCC developers will > > eventually start to dwindle. Without developer renewal, GCC will > > naturally die out. This cycle has happened many times before and it > > will continue to happen. Yet, it would be interesting to have two or > > more strong competing open source compilers. The cross-pollination > > that open source competition encourages is beneficial to all (users > > and developers). > > > > > > Diego. > > > As I am happy to be finding out though, even from RTL (old pdfs and > stuff :)) GCC wasn't what I thought it was, to quote earlier: > ---------------------------------------------------------------------------------------------------------- > I really have a theory here, I think (like me! I came here in the hope of > 'fixing' GCC from what I thought it was to what it is because I, suppose I > am loyal, I don't really like BSD, the lack of obligation to keep things > free, anyway that'll start a dispute probably so don't worry) it's all the > bad press, my impression was GCC is really old and archaic, not very good > for developing new optimisations, had a crap IR and there was this newcomer > that only made these problems known because it fixes them. > > > I know now that most of them were wrong BTW! > Ah, well - the old issue that LLVM has just become a very good > marketing machinery > (and we've stayed at being a compiler - heh). > > Richard. > < > You see my point though right? > Alec > ---------------------------------------------------------------------------------------------------------- > > Is it not just bad press? The articles perpetuate the "Wow look how easy > clang is" which no one expects of GCC.
If you're looking for an easy introduction to GCC (and know Python) you might want to try my Python plugin for GCC: http://gcc-python-plugin.readthedocs.org/en/latest/ It lets you write new GCC passes in Python, exposing GCC's data structures as Python classes and objects, which I hope will make things considerably easier for newcomers. (it covers the tree and gimple parts of the IR; it doesn't really handle RTL yet). It can also generate various nice visualizations of the internals, and being in Python it's relatively easy to hack on. Hope this is helpful Dave [oh, and Uday: am very much enjoying reading your Data Flow Analysis book - thanks for writing it! ]
