This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SC issues revised


Tom Lord writes:

> In general, I think that more money ought to be spent on GCC,
> specifically to make improvements that are of a general nature --
> valuable to everyone interested in GCC.  I think that the political
> structure of project governance correlates directly with the
> probability that such spending can occur: the SC has the opportunity
> to define a framework that companies can pay into for general
> improvements.

You seem to believe that a pot of money could somehow be generated, even
in these tough times.  I can't imagine such a thing happening. Companies
are reluctant to pay for "general improvements" because they have limited
resources and would rather just wait for those general improvements to
appear.  Instead, we tend to get improvements because some company paid
some GCC contributor (CodeSourcery, Red Hat, SuSE, ACT or an independent
contractor) to do something specific, because the paying party believed
that the change would not happen without such a contribution.

Even if such a pot of money were to become available, I would be against
trying to turn the SC into a body that would dole it out.  We'd have to
form a nonprofit, and SC members would have to deal with extra legalities
to be officers of this nonprofit.  Some members would have a conflict
of interest, if the SC were to put out some work for bid and the bidders
employed SC members.  I wouldn't want to bother: if you could
make extra money appear, let the FSF manage it; the SC could give advice
as to how to dole it out, perhaps.

> So I'm trying to build a list of specific technical goals that most
> maintainers will agree are desirable, and achievable, but that aren't
> currently likely to happen due to resource constraints.  I'd like to
> test the waters with three of these:
> 
> 
> 	1. Continuous release management.
> 
> 	   Changes to the trunk should not cause the trunk to vary
> 	   from a releasable, maximally tested condition.  At the
> 	   same time, this new constraint shouldn't slow down the rate
> 	   at which changes can be made, or make it too difficult to
> 	   make changes.

Unfortunately, your second sentence contradicts the first.  Your first
condition makes significant change or improvement almost impossible
except for minor fixes.  Mark Mitchell's scheme for establishing time
periods for development and time periods for stabilization is an attempt
to address these two contradictory goals.  Any suggestions for
improvements would be great.

> 	2. Improved testing infrastructure.
> 
> 	   The test suite should be complete enough that there is
> 	   little value in, say, running GCC through a proprietary
> 	   test suite.  There should be better support for testing for
> 	   performance regressions, both of the compiler and of
> 	   generated code.  There should be a (more complete) pool of
> 	   platforms dedicated to testing, and a queue to which
> 	   contributors can submit branches for testing.

I would welcome efforts to improve the testing infrastructure, but this
can be done by volunteers under our current structure.  If we had a
very easy-to-use web-based test infrastructure, we could probably easily
recruit people willing to donate the needed CPU cycles.  If we could give
people an easy-to-run script that they could just fire off from cron and
send us results, we could probably get lots of folks to run it.

I think that this is the project that we can do the soonest, because there's
no big barrier to just doing it.

> 	3. Deep architectural improvements.
> 
> 	   I have heard, but don't fully understand the issues, that
> 	   GCC is noticeably far behind various proprietary compilers
> 	   in terms of the quality of code generated.  Some of the 
> 	   issues are "nobody has done much work on that target", but
> 	   some of the issues are "gcc would need deep, pervasive 
> 	   changes before it could include similar optimizations".
> 	   There should be support and resources for planning and
> 	   executing those kinds of changes.

We need to address #3, but it completely contradicts #1.  One major issue
holding us back is that GCC has way too much mystery cruft that only a
few gurus understand, and these gurus are too busy.  This makes it much
harder for people to contribute to the compiler.  A first stage might
simply consist of an effort to produce excellent internals documentation,
and to try to couple the production of that documentation with some
architectural cleanups (if it's too hard to understand and can't be
explained, or if the same feature is used for two purposes, it can be
fixed).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]