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: Will tree-ssa be GCC 3.5?


On Sunday 30 November 2003 08:03, Phil Edwards wrote:
> Sorry, I just don't see what we gain from calling it 4.x when there's
> no user-visible change big enough to deserve a bump in the major number.
> Say that tree-ssa enables us to add a bunch of optimizations, and we do,
> and the inlining strategies settle down, and compile times stop going
> through the roof,

Failing to fulfill these would be a failure of the project ;-)  These three 
points in fact are among the major goals of the tree-ssa project.  Have you 
looked at it recently?  There already _are_ a bunch of new optimizations. 

> and we can selectively enable/disable warnings inside code,

Get people to agree how diagnostics should be labeled/numbered/whatever, and 
together with unit-at-a-time compilation this should be doable after 3.4 goes 
out.
(In fact it would be easier with tree-ssa since more and more warnings are 
being moved out of the backends to up front where they belong ;-)

> and do all the other things that our users have been asking for --
> once those things are /done/, then we can hold up 4.0 and say, "Behold!"

Then there will never be a major version number bump because we tend to 
implement a few new features with each release, not all at once.  So people 
will always argue that "the change is not big enough" from a user POV.

> As things stand, we'd be forking a branch, gcc3 would receive almost no
> attention, and all we could say to the users is, "We hope that 4.x will
> eventually earn its name."

It is OK for a (N+1).0 release to be not as good as the latest release in the 
N release series.  This happens everywhere and all the time.  See FreeBSD 5.0 
for example, or linux kernel 2.4 and now again for 2.6 (assuming a minor 
number change for a kernel is as significant as a major number would be to 
gcc).

I believe that very significant internal rewrites _do_ deserve a new major 
version number. Increasing the minor version number would indicate evolution: 
small, incremental changes.  IMHO tree-ssa is revolution: a whole new way for 
gcc to look at the compilation process with a new IR, at last a working SSA 
framework, a complete re-ordering of code-improving passes, complete breakage 
for all front ends outside the GCC tree, and so on.  This is _not_ evolution, 
and users will notice.

Gr.
Steven


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