This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Criteria for GCC 4.0
Steven Bosscher wrote:
(No this is not a technical argument, but a valid _economic_ argument.
Many of us make money by working on GCC, and we have to sell that
work as a "product". Why can't GCC give a little help by not being so
anti-marketing.)
We are in whole-hearted agreement here.
By your reasoning, GCC 3.4.0 should have been GCC 4.0, because of the
new C++ front end (which is undoubtedly a far more visible change than
the new fortran front end) which does break compatibility.
Indeed, the new C++ front end has caused great stress for those trying
to build distributions with GCC 3.4. I've been working with this for
Gentoo's distro, which still has a few packages that fail with GCC 3.4.
This was a major change that should have been communicated more clearly.
The results of the Acovea project need to be studied carefully and
taken into account. Perhaps -O2 should turn on a reasonably good set
of optimizations for the platform at hand, rather than a static set.
And again, this change is no more user-visible than tree-ssa, so by
your own arguments it wouldn't justify a new major version number.
There is also a technical reason against making options depend on the
target platform: coverage. It's no big secret that the majority of
gcc testing happens on only 3 or 4 platforms. If some options were
disabled for these most-used platforms, bit rot would probably set in
rather quickly.
I am of mixed feeling on this, believing that Acovea may work best as an
external tool. It may not be possible to define one set of
"platform-specific" options, given that an "optimisation" for one
algorithm (or processor variant) may be a "pessimism" for another.
That said, GCC's current choices for -O2 and -O3 increase compile time
without providing a major improvement in code performance. Refining
these option sets would result in faster compile times without losing
significant performance in the generated code. Those who require the
fastest code can then rely on tools like Acovea.
Our documentation needs to help, not hinder. (The tone and grammar is
wildly inconsistent. The sections are in no clear order. Very little
is up to date.)
And how does this break backaward compatibility? I'm not going repeat
myself again...
Documentation should not be a criteria for a new version number.
*However*, the current documentation is problematic at best, and
downright misleading, absent, and impenetrable at worst. The GCC
economic model needs to be changed such that documentation is a priority.
But please notice that we _do_ have breakage of backward compatibility
in the next GCC release, at least for fortran with a new front end, for
Java because of the new ABI, and for Ada which probably will not be
included at all. Also don't forget we now have variable tracking, which
means we require our users to upgrade to GDB 6.1 or better.
After reading the above, I am reminded of past conversations, and I tend
to agree that this release needs to be 4.0, not 3.5. However, almost
nothing mentioned above (besides the GDB requirement) is specific to C
developers, who appear to be a dominant factor (for obvious and valid
reasons). If the criteria is based on the mass of users -- most of whom
use C or C++ -- then I can see why they are resisting a bump to 4.0.
..Scott
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing