GCC 4.0 vs. 3.5

[Steven Bosscher]

On Apr 17, 2004 04:19 AM, Zack Weinberg <zack@codesourcery.com> wrote:

> 
> I continue to believe that major version number increments should only
> happen when backward compatibility is deliberately broken, and not in
> a way that users have been acclimatized to, e.g. the continual
> revision of the C++ abi doesn't count.

You have said this many times before.  Others believe different things.  I believe that a major rewrite of basically the whole global optimizer is worth a new major number.

Mark called tree-ssa an implementation detail, but I believe this greatly underestimates the impact of such a huge amount of work on such a crucial part of an optimizing compiler.  Obviously we're making sure not to break backward (binary) compatibility, but that doesn't change the fact that the user expectations of GCC will have to change a lot after tree-ssa is merged.  We don't get just a new optimization framework, but also all the changes in resulting code, debugging information, new flags and options with some old ones disappearing, etc.

Simple example: Users fiddling with flags will now have to update their configure and build scripts to enable/disable tree passes.  The effect of, say, -fno-gcse, is very different on mainline than on tree-ssa.  And after the merge I expect us to remove or trim some of the RTL passes, in which case some flags and params (cse-max-path-length and such!) will be removed.  This _does_ have an impact on users, and _may_ break backward compatibility for some users.

I repeat what Geert already said: A lot of internal code will be different from previous releases, and this code is not as well tested as the existing code base (no matter how many FC2s we compile :-).  Releasing a new major version (a .0 release) communicates this risk better than anything else.

Another reason why a major version number jump may be justified is if (when?) we manage to achieve the promised speedups of the compiler.  The whole gcc3 has a bad name in that respect, and moving to gcc4 would make a statement: "We're past that now, this new compiler really is a major improvement".  I personally see nothing against a little marketing like this, all compiler vendors do so (just look at the major numbers of, say, icc and MIPSPro).  I'm sure you very much disagree, but hey, for the sake of discussion ;-)


> Incorporating the new Fortran front end is a big enough change - but
> only for users of Fortran.

There is also the disabling of Ada, until GNAT is updated to use the new tree framework.  So at least two languages feel a big impact.  I think that the changes are also very significant for Java, which AFAIK would not write out optimized byte code before, but can do so now that we optimize trees (???).  That would make it three languages.


> Frankly, if a change were on the table that *would* justify bumping
> the major version number of the entire compiler collection, I expect
> it would be shouted down in short order.
>
> I only countenanced the 2->3 bump because it was necessary to make
> clear to users that the forked development effort was over (and
> because the internal version numbers for EGCS were chosen incorrectly,
> such that we were up a creek).  The 1->2 bump was well before my time
> so I won't comment on it.

In your reasoning, there will never be a bumping of the major version number.  The whole goal is to _avoid_ the only situation that you say would justify a new major number.

The kind of changes you describe are simply never going to happen (or at least, they should not), because compiler development is incremental in nature.  And if you look at tree-ssa, the increment is considerable, far larger than the typical changes from one minor release to the next (with the exception of the new C++ front end perhaps), and comparable to the kind of changes from gcc2 to gcc3.   Certainly large enough to justify a major version bump IMVHO.

Gr.
Steven