Criteria for GCC 4.0

[Scott Robert Ladd]

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